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The  System  and  Software  Simulator  (S3)  is  a  digital  event  simulator 
written  in  FORTRAN  IV  and  designed  to  perform  simulations  of  computer 
systems  hardware  and  software  and  of  the  workload  being  applied  to  the 
system. 

This  and  the  other  three  voluams  constitute  the  cos^ilete  docusMOtation 
available  on  S3.  Volume  I  describes  the  inputs,  outputs,  smthods  and 
capabilities  of  S3.  'Volume  II  contains  the  flowcharts,  narrative 
description  of  the  flowcharts,  layouts  and  descriptions  of  the  tables 
utilised  by  S3.  Voluam  III  contains  descriptions  of  the  asseadtly  language 
used  for  preparation  of  input  to  S3,  of  the  macro  capability  of  the 
asfembler,  and  of  the  modifications  made  to  S3  to  provide  additional  output 
data.  Volume  IV  is  the  program  documentation  on  the  internal  workings  of 
the  assembler.  It  consists  of  table  descriptions,  flow  charts  and 
narratives,  and  file  descriptions. 

These  volumes  are  a  collection  of  documentation  delivered  ’jmder  two  separate 
contracts.  They  have  not  been  edited  and  as  such  are  considered  working 
papers. 
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Th«  documentation  on  the  System  and  Software  Simulator  (S3) 
contained  in  this  and  the  other  three  volumes  is  considered  a  working 
paper  and  no  claims  are  made  as  to  its  accuracy.  There  has  been  nc 
attempt  to  edit  the  information.  Discrepancies  and  inconsistencies 
are  known  to  exist. 

This  information  is  being  released  as  a  service  to  interested  parties 
and  to  satisfy  the  numerous  requests  for  informati'*  on  S3. 

The  documentation  of  S3  is^contained  in  four  volumes.  Volumes  I 
and  II  are  contract  end  items  delivered  under  contract  number 
DA-49-083  OSA-3306  and  contain  the  technical  descriptions  of  S3. 
Volume  I  describes  the  inputs,  outputs,  methods  and  capabilities 
of  S3.  Volume  II  containt  the  flowcharts,  narrative  description  of  the 
flowcharts,  layouts  and  descriptions  of  the  tables  utilized  by  S3. 

Volumes  III  and  IV  contain  the  documentation  delivered  as  contract 
end  items  under  contract  number  DAAB09-68-C-01 18.  Volume  III 
contains  descriptions  of  the  assembly  language  used  for  preparation  of 
input  to  S3,  of  the  noacro  capability  of  the  assembler,  and  of  the 
modifications  made  to  S3  to  provide  additional  output  data.  Volume  IV 
is  the  program  documentation  on  the  internal  workings  of  the  assembler. 
It  consists  of  table  descriptions,  flow  charts  and  narratives,  and  file 
descriptions. 
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SECTION  1 


INTRODUCTION 


1 . 0  GBfERAL 

A  digital  event  simulation  of  a  coin)Utlnc  system's  performance 
Masures  it's  success  in  terms  of  the  accuracy  with  which  the  simulation 
approximates  a  real  system's  performance.  To  achieve  acceptable  accuracy 
It  Is  nocesaary  for  the  digital  event  simulation  to  provide  representation 
for  four  specific  Items; 

A.  Hardware 

B.  Users 

C.  OroratiPf:  Systin 

D.  Piles 

In  providing  the  model  required  for  a  properly  accurate  simulation, 
it  is  necessary  that  a  high  detail  of  representation  be  made  available. 

In  particular,  it  is  required  that  all  of  the  performance  characteristics 
of  each  of  the  hard  wired  equipments,  as  well  as  of  the  system 'a  software, 
be  represented.  It  is  necessary  that  the  dynamic  structural  componeiil.": , 
specifying  topology,  have  a  prsence  in  the  simulation  as  well.  The  per¬ 
formance  of  this  simulation  moticl  is  dependent  solely  upon  the  accuracy 
of  the  data  presented  to  it. 


1.1  KAJIUWARE 

Hardware  description  for  purposes  of  simulation  encompasses  a  descrip¬ 
tion  of  peripheral  devices;  transmissions,  memories  and  the  Q’U's.  The 
hardware  configuration  description  is  independent  of  any  dynamic  topological 
connections,  and  is  strictly  functional,  relating  to  the  performance  properties 
of  the  equipments  involved.  A  brief  description  of  the  performance  properties 
to  be  represented  for  the  peripheral  devices  is  explained  below. 


1.3  PERIPHERAL  DEVICES 

There  arc  two  ty'pc.s  of  peripheral  devices  of  inlere.^t  in  a  comiiuting 
sysl-  The.se  arc  sequential,  ar.d  random  across. 

A,  The  sequential  type  includes; 

1.  Card  rc.idcrs 
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2.  Paper  tape  readers 

3.  Line  printers 

4.  Magnetic  tapes 

B.  Random  access  includes: 

1.  The  random  access  disc  and  drum 

2.  The  card  random  access  devices 


1.2.1  Sequential  Devices 

The  sequential  device  specifications  of  interest  for  the  purposes 
of  simulation  are  time  to  transmit  a  record,  the  time  required  to  traverse 
an  inter-record  gap,  and  any  penalty  time  that  may  be  associated  with  time 
dependent,  sequential  Input-Output  (I/O)  relative  to  the  particular  device 
Thus,  on  a  magnetic  tape,  the  transfer  of  a  specified  block  of  data  occurs 
at  a  given  rate.  The  time  to  traverse  enough  tape  to  pass  to  the  next 
block  is  also  a  necessary  specification,  and  finally  STOP  START  time  and 
any  associated  penalty  time  for  exceeding  the  STOP  START  interval  must  be 
represented. 


1.2.2  Random  Access 

For  random  access  devices  there  are  two  basic  timing  considerations 
to  be  ccrisidcicd.  Certain  devices  require  seek  time,  which  is  indepen¬ 
dent  of  the  data  transfer  time  involved.  As  in  the  case  of  a  sequential 
device  however,  once  data  is  transferred  it  is  transferred  in  a  block 
unit,  and  again  there  may  be  INTER-RECORD  time  that  might  be  considered 
to  bo  equivalent  to  the  latency  time  on  a  rotating  random  access  device. 


1.3  TRANSmSSIONS 

The  transmissions  that  arc  specified  for  simulation  represent  the 
connection  between  the  peripheral  devices  and  memories  of  the  system. 
There  are  two  t;,-pcs  of  transmissions  used  fo,  simulation;  the  wire  and 
the  cliarnel.  A  transmission  has  a  method  of  data  transfer,  such  as  bit- 
par..jiex  or  byle-sequential . 

1.3.1  Wire 

For  a  wire  to  transmit  such  a  unit  there  will  be  required  an  amount 
of  Centjal  I’l-ocoss  j  ng  Unit  (CPU)  activity. 


1»3.2  Channel 


A  channel  is  capable  of  transmitting  a  specified  collection  of  such 
units  without  any  CPU  assistance.  Thus  the  channel  exhibits  simultaneous 
operation  with  the  system’s  Cl’U,  and  the  wire  does  not. 

Sp  ecification  of  transmission  performance  for  simulation  purposes 
therefore  requires  a  statement  of  the  data  transfer  unit,  the  rate  at 
which  transfer  is  accomplished,  and  the  type  of  the  transmission.  In 
addition,  it  is  necessary  to  specify  the  point  at  which  the  total  I/O 
transmission  rate  saturates  the  available  memory  cycle  time  for  a  given 
memory  module. 

The  performance  properties  of  interest  lor  a  module  of  memory  is  its 
size,  in  addressable  units.  For  simulation,  interest  centers  on  the 
separately  powered  memory  module  so  that  it  may  be  isolated  to  take 
account  of  the  effect  of  memory  interference  on  available  CPU  access 
time.  The  specification  of  the  simulation  model  requires  that  the  number 
of  such  separately  powered  memory  modules  be  given. 

The  performance  characteristic  of  the  CPU's  of  the  system  is  the 
rate  at  which  it  is  able  to  execute  various  classes  of  instructions. 

These  instruction  classes  are  for  add,  multiply  and  divide  type  instructions. 
As  in  the  case  of  the  specification  of  memory  modules  for  a  simulation, 
it  is  necessary  to  specify  as  well,  the  number  of  CPU's. 

Therefore,  S3  requires  a  performance  specification  for  each  of  the 
elements  to  be  simulated  within  the  above  described  four  categories. 
Additionally,  information  is  required  in  order  to  specify  the  inter¬ 
connections  between  peripheral  devices  and  memories,  and  between  memories 
and  CPU's.  This  topological  interconnection  of  information,  and  the 
performance  specification,  forms  the  configuration  data  for  the  simulation 
model.  Thus  the  simulator  machine  provides  the  potential  for  expression 
of  virtually  any  tjTJC  of  system  configuration  for  the  purpose  of  simulation. 

EXAMPLE: 

Configuration  data  specifying  two  CPU's  and  tv.o  memories  may  be 
further  specified  to  interconnect  CPU’s  and  memories  such  that  each  CPU 
has  access  to  both  memories.  This  would  represent  a  multiprocessor 
cenfiguf alien ,  such  as  the  GK  600  series.  Also  two  CPU's  and  wo  memories 
may  specify  a  1401-7090  Main-i^atelli  to  system,  by  specifying  that  each 
of  the  CPU's  is  connected  to  one  and  only  one  of  the  mem.  Ics. 


1 . 4  USKl? 

The  various  hardware  cciuii)ments  for  which  the  configuration  data 
described  above  provides  performance  and  topological  specification  is 
loaded  by  the  users  of  the  system  in  terms  of  the  amount  of  time  required 
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by  programs  on  these  several  hardware  resources.  These  resources  are 
loaded,  as  well,  by  the  operating  system.  Since  the  operating  system's 
function  Is  to  distribute  resources  to  the  user's  programs,  this  will  be 
explained  separately.  In  order  to  distinguish  between  user  and  opera¬ 
ting  system  programs,  we  shall  refer  to  the  former  as  worker  programs. 

A  worker  program,  prior  to  Its  execution,  represents  a  potential 
load  on  the  computer  system's  resources.  The  program  itself  requires 
memory  space,  and  its  execution,  CPU  time.  Futhermoro,  its  1/0  activity 
will  refer  to  flics  resident  on  peripheral  devices  available  in  the 
system  and  these  devices  are  reached  by  the  specified  transmissions. 

The  use  of  a  system's  facilities  by  worker  programs  is  referred  to  as 
potential  because  the  actual  use  of  facilities  is  dynamically  determined 
at  the  execution  time  of  the  worker  program  itself.  Therefore,  in 
simulation  it  is  necessary  to  represent  the  several  potential  load 
possibilities  that  a  worker  program  may  exert  or.  the  simulated  system. 
This  is  accomplised  by  allowing  each  of  the  worker  programs  whose  per¬ 
formance  in  the  system  is  to  be  simulated,  to  be  represented  by  what  we 
shall  refer  to  as  a  worker  program  graph. 


1.5  WORKER  PROGRAM  GRAPH 

The  program  graph  is  defined  as  a  collection  of  directed  edges  and 
nodes.  Edges  that  leave  a  node  are  referred  to  as  exit  edges,  and  those 
that  enter  a  node  as  entering  edges.  An  exit  edge  is  associated  with 
two  values.  The  first  of  those  two  values  is  the  probability  of  choosing 
this  exit  edge  on  leaving  the  node.  Thus,  if  there  are  two  exit  edges 
from  a  given  node  and  the  probability  of  taking  one  edge  is  .30,  then 
the  probability  of  taking  the  second  edge  would  be  .70.  (figure  1-1). 

The  second  value  associated  with  an  edge  is  a  "statement’'. 


^  NODE 


.70  -  prob.  of 
selection 


Figuri.  1-1.  EDGES  AiN’D  NODES 
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The  collectjon  ol  nodes  and  edges  of  a  program  graj  o  to  represent 
tlic  possible  directions  that  the  logic  of  a  worker  program  follow 
during  its  execution.  Nodes  represent  Junction  points  for  ti  e  possi¬ 
bilities,  the  edges  represent  the  operations  that  the  worker  program 
would  carry  out  if  the  edge  were  selected  at  execution  time.  Thus,  the 
program  graph,  as  a  collection  of  nodes  and  edges,  is  coir^arable  to  the 
process  chart,  which  Is  u‘^ually  the  first  stage  of  an  actual  programming 
effort. 


1.6  EDGE  STATKM>2^TS 

Edge  statements  to  indicate  the  possibilities  that  the  simulator 
makes  available  for  representation  of  the  potential  load  exerted  by  a 
worker  program  on  the  simulated  system  follows. 

The  statements  may  be  divided  into  three  categories  such  as: 

A.  CPU  utilization 

B.  1/0  utilization 

C.  Control 

A  list  of  edge  .statements  designed  for  specification  of  CPU  utili¬ 
zation  arc  in  Table  1-1.  Each  of  these  statements  represent  a  way  of 
expressing  a  requxrciiont  for  the  CPU,  in  term.s  of  the  logical  operation 
exercised  by  execution  of  the  t^gc  with  which  it  is  associated. 


Tabic  1-1.  EDGE  STATEMENTS,  CPU  UTILIZATION 


MOVE  N 


move  N  core  memory  data  units 
on  the  m<.lnfrnmo 


MOVE-E  N 


move  and  edi t  N  core  memory 
data  units 


.  COlPUTE  N 


choose  a  mix  of  instruction.s 
relative  to  the  number  N 


MATH  A,  B,  C 


execute  A  adds,  B  irul  tip  lies 
and  C  divides 
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1.6.1  HOVE  Statcncnt 


The  HOVE  statement  causes  the  simulator  machine  to  determine  the 
number  of  Instructions  that  I’ould  have  to  be  executed  in  order  to  accom~ 
pllsh  the  movement  of  the  N  data  units.  This  number  of  instructions  is 
then  translated  into  an  amount  of  CPU  time  required  to  execute  according 
to  the  specification  given  in  the  configuration  data. 


1.6.2  HATH  Statement 

The  HATH  Statement  al lea's  the  worker  program  to  spcciri’  the  number 
of  add,  multiply  and  divide  operations  involved  in  the  confutation  of  a 
formula,  or  collection  of  formulas.  The  simulator  machine  interprets 
each  of  these  parameters  into  a  number  of  instructions  to  be  executed  and 
then  interprets  the  result  into  the  time  required  forthc  CPU  to  execute, 
using  the  configuration  data  specification  for  the  CPU.  This  is  accom¬ 
plished  in  conjunction  with  a  Gibson  Uix  fo.'mula  to  indicate  execution 
memory  access  overlap. 


1.6.3  COIPUTE  Instruction 

The  COMMUTE  instruction  provides  the  creator  of  a  worker  program 
with  capability  for  expressing  a  CPU  require’aent  in  lieu  of  any  more 
Specific  knowledge  of  the  activity  expected  ^or  the  program. 


1.7  1/0  UTILIZATIO.N  STATEMENTS 

The  utilization  statements  made  available  by  the  simulator  are 
explained  in  the  following  text.  Because  there  is  an  application  of 
S3  for  which  it  is  highly  desirable  that  the  worker  programs  be  device 
independent,  the  techniqxios  employed  by  the  simulator  reduce  the  number 
of  I/O  slatementr  to  four.  These  four  statements  are  listed  in  Table  1-2. 
The  associated  parameter  is  an  ordinal  file  number.  This  number  is  local 
to  the  program  graph  within  which  it  appears  and  identify^  that  file 
within  the  program. 


Table  1-2.  I/O  STATCOEiTS 


(B’FN 

A 

open  ordinal  file  A 

CLOSE 

A 

close  ordinal  file  A 

READ 

A 

read  next  record  from  ordinal  file  A 

WRITE 

A 

write  next  record  to  ordinal  file  A 
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When  an  1/0  statement  is  encountered  by  the  simulator  machine  in 
the  course  of  a  sinmlated  execution  of  a  worker  program  graph,  the  ordinal 
file  number  is  used  to  locate  the  simulated  file  o-;  the  peripheral  device 
on  which  it  resides.  The  simulated  operating  system  determines  the 
order  of  access  by  this  worker  program  to  the  device,  and  when  the 
simulated  1/0  operation  is  initiated,  thv>  simulator  machine  coii|>utes 
the  time  required  to  find  the  file  on  the  device,  and  to  transfer  a 
block  of  information  from  the  device  over  the  selected  transailsslon  to 
the  memory. 


1.7.1  WEM  Statement 

The  S3  provides  a  mechanism  for  the  user  to  specify,  among  other 
thing.s,  the  number  of  buffers  to  be  retained  in  the  memory  for  each  of 
the  ordinal  files  referenced  by  a  worker  program.  The  purpose  of  the 

statement  is  to  initiate  the  filling  of  all  buffers  for  the  ordinal 
file  designated. 


1.7.2  QX)SE  Statement 

The  a/)SE  statement  closes  the  designated  file  by  emptying  tho 
buffers  via  simulated  output  operations. 


1.7.3  CONTROL  Statements 

Table  1“3  gives  tho  several  control  stateuents  that  the  simulator 

S  ^ 

mokes  available  and  by  means  of  which  the  creator  of  a  worker  protram 
graph  may  specify  conditional  and  unconditional  trunsfer  loops  through 
portions  of  the  grapli  the  call  of  subroutines,  ard  finally  termination 
of  the  simulated  execution  of  h's  worker  progium. 


Table  1-3.  CONTROL  STATDIilNTS 


TRANS 

A 

transfer  to  statement 

A 

TRANS-1* 

A,U 

with  probability  A,  transfer 
to  atatei.'ent  B 

Loa> 

A.B 

transfer  to  statement 
B  times,  after  which, 

A ,  as  a  loop, 
go  in 

BOF 

A 

transfer  to  vt.Htcmer.t 

A  on  cnd-of-file 

conti  nuvd 


*51? 
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Tabic  1-3. 


(Continued) 


8UBR  A 

execute  the  subroutine 
stateMnt  A 

starting  at 

BUT 

return  from  subroutine 

TBRM 

terminate  execution  of 

the  worker 

Of  the  several  control  atatonents  llstc:!  in  Table  1-3  the  Snd  of  File 
(nP)  statenent  nay  be  unfamiliar.  The  specification  of  a  file  (  to  be 
eo\'«tred  later)  includes  its  size.  When  enough  reads  for  an  ii^ut  file, 
or  writes  to  an  output  file,  have  been  encountered  during  the  sinulatcd 
execution  of  the  worker  program  to  equal  the  number  of  data  units  in  the 
file,  the  Simulator  nachlnc  indicates  this  by  setting  a  flag  for  that 
file.  If  the  user  elects  tu  use  the  end-of-flle  condition  in  the  program, 
it  is  done  with  the  EOF  statement.  If  this  statement  is  not  used  then 
the  condition  of  the  end-of-flle  flag,  as  established  by  the  simulator 
machine,  has  no  effect  on  the  simulated  execution  of  the  worker  program. 

With  the  edge  statements  that  S3  iiakes  available  to  its  users  for  the 
specification  of  worker  program  graphs,  it  should  bo  clear  that  the  pro¬ 
cess  chart  of  an  actual  worker  program  has  a  close  IdentlflcatH  with 
this  representational  form  for  simulation.  An  example  of  this  is  shorn 
in  the  process  diagram  (figure  1-2).  The  program  flow  for  diagram 
(figure  1-2)  is  shoan  in  figure  1-3,  and  figure  1-4  shows  the  "programming" 
of  the  program  flow  using  the  simulator  language. 
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1.8  THS  OPERATING  SYSTEM 


One  comaon  characteristic  for  an  operating  system  and  worker  programs 
is  that  they  are  both  programs.  Bach  can  bo  represented  by  flow  charts, 
and  for  simulation  purposes  by  process  charts.  This  common  characteristic 
of  the  techniques  used  for  the  representation  of  a  worker  program  via  the 
program  graph  and  simulator  machine  statements,  are  suitable  for  the 
representation  of  on  operating  system.  The  problem  of  drawing  a  pro''ess 
chart,  and  the  progra.a  ernph  for  an  operating  system  brings  up  one  of  tne 
basic  differences  between  an  operating  system  and  worker  program. 
Specifically,  the  logic  of  the  execution  of  the  worker  program  depends 
on  the  data  on  which  it  operates.  The  logic  of  the  execution  of  an  oper- 
atirig  system  depends  on  the  needs  of  the  particular  worker  programs  to 
which  it  is  distributing  the  system's  facilities.  Consequently,  the 
items  on  which  the  operating  system  must  perform  its  functions  arc  the 
•orkrr  programs  themselves,  or,  more  accurately,  representative  names 
for  these  worker  programs.  Therefore,  if  worker  programs  A,  B,  and  C 
are  resident  in  the  simulated  memory  of  a  one  CPU  system,  and  all  three 
of  them  are  available  for  execution  seeking  the  CPU  facility,  it  is  the 
operating  system's  responsl bll ty  to  determine  which  of  the  three  will 
next  gxin  access  to  this  facility,  and  to  defer  the  execution  of  the 
remaining  two.  By  this  method  A  may  bo  selected  as  the  current  operating 
program  and  be  given  the  CPU  facility,  to  continue  its  simulated  execution. 
Simultaneously,  the  operating  system  must  defer  the  execution  of  programs 
B  and  C,  by  placing  thoir  naraes  in  a  list  br  queue  Indicating  deforrment. 


1.8.1  Additional  CPU  Statements 

It  is  therefore  necessary  to  augment  the  collection  of  CPU  odg<* 
statements  to  provide  the  necessary  capabilities  for  the  conipleie 
Specification  of  an  operating  system  program  graph.  Table  1-4  lists 
additional  S3  statements  and  cxplBin^  each  application.  Careful  review 
of  these  st.itcmonts  indicates  that  any  operating  system  can  be  success¬ 
fully  represented  for  simulation,  ranging  from  the  simple  batch  prcKrcssor, 
to  multiprogramming  operating  systems  for  a  single  CPU,  multiprocessing 
operating  systems  for  multiple  CPU's  and  operating  systems  for  the  con¬ 
trol  of  mul ti -computers . 


1.8.2  Interrupt  Technique 


To  coEplete  ar.  oji.'ralirg  systen 
available  for  the  represvntntlon  of  i 
method  for  the  simulation  of  inlerruj> 
accor;p  1  i  s  hv  d  by  ru-an-:  of  an  Interrupt 
which  Is  a  list  of  simulator  nach'nc 
by  the  lise;-  Jn  the  prt  parat  i  on  of  the 


specification  a  tochnir.ue  avist  be 
nterrtipts,  S3  provide.*  a  general 
I*  through  the  sy-stem.  Tills  Is 
vector  in  the  simulator  n’schinc 
statemi'nts  that  have  been  Speclficil 
operating  systesi  graph. 
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Tabic  1-1.  ADDITIONAL  S3  STATEMENTS 


MEMORY 

A,B,C 

used  to  query  the  current  state  of  the 
Bcmory  map.  The  parameters  specify 
conditions  for  the  query. 

ALLOCATE 

A.B 

used  to  assign  memory  and  Rodlfy  the 
neiBory  map 

DEALLOCATE 

A,B 

reverse.^  the  fiuictions  of  ALLOCATE 

PACK 

A.B 

to  modify  the  mcriory  map  without  allocation 

EXAMINE 

A.B 

examine  queue  A  according  to  criteria  B 

PLACE 

A.B 

place  program  or  1/0  call  A  into  queue  B 

SELECT 

A.B 

select  program  or  I/O  call  A  from  queue  B 

BUFFER 

used  to  control  buffering 

SEEK 

used  to  locate  a  named  file  on  its  device 

10  READY 

A 

determine  the  cxecutabi li ty  of  the  next 

I/O  call  in  queue  A 

10  ADVANCE 

initiate  a  given  1/0  operation 

10  TE31M 

A 

search  queue  A  for  an  1/0  termination 
condl tion 

INTERRUPT 

A.B 

interrupt  CPU  number  A  for  Condition  B 

DISAHI.E 

A 

disable  interrupts  A 

ENABI.E 

A 

enable  interrupts  B 

aocK 

A 

set  clock  to  time  A 

The  user  mny  a'-stK;!  nlc  cnch  item  of  the  inlcrruiit  vector  with  any 
Sl.'.tciaent  of  hl5  ct’.ulco,  bvit  tlu-  statement  selectej  *111  generally  be 
TRANS  with  its  paraneler  i  f  yi  ng  a  particular  location  in  the  operating 

sysl'-m  graph.  The  geiu  ral  ni.'tluHl  for  I/O  interruyt  hnntlling  is  as 
follows:  aflci'  curpletioM  of  a  sinulalecl  1/0  operation,  the  slsiulaletl 

execution  of  the  current  ojirratine  program  is  inlerrv'ptrd  and  the  nest 
sianil.ator  Bachitu-  staltr.  -m  i«>  i- -  executed  is  selci  led  fron  the  interrupt 
vector  1  tcPi  associatevi  with,  ll.e  1/0  inter!  upt  titat  h.-s  fKcvii-red.  Therefore, 
if  the  state»ent  in  the  r-eleitrvl  int'-»i«pt  xecloi-  item  is  a  transfer  into 
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a  particular  portion  of  the  operating  system  graph  (most  1.  kely  this  will 
be  to  the  interrupt  processing  portion)  then  the  simulation  of  operating 
system  action  on  tlie  occui'rence  of  a  particular  I/O  interrupt  is  initiated. 

NOTE 

The  operation  of  the  interrupt  function  of  the  simulator 
machine  resembles  that  of  all  real  systems  in  that  the 
current  execution  state  of  the  inteirupted  current  opera¬ 
ting  program  is  retained  for  that  program,  so  that  when 
next  selected  for  resumption  of  its  execution,  that  ex¬ 
ecution  is  continued  from  the  point  of  interrupt. 


1 . 9  GENERAL  CONCEPT 

The  techniques  thus  far  described  invest  the  simulator  machine  with 
properties  that  eclio  tlie  logical  characteristics  of  an  actual  computer. 
Thus,  configuration  data  associates  the  simulator  machine  with  a  specific 
set  of  peripheral  devices,  transmissions,  memories  and  CPU's,  The 
worker  and  operating  system  program  diagrams,  in  terms  of  simulator 
machine  statements,  then  appear  to  the  simulator  machine,  and  are  acted 
upon  by  it,  in  precisely  tlie  same  way  that  an  actual  computer  accepts 
and  executes  actual  programs.  The  important  point  is  that  this  is  the 
general  characteristic  of  the  simulator  machine.  By  means  of  configura¬ 
tion  data  and  program  diagrams  particular  characteristics  arc  specified 
for  the  system  in  whose  simulation  we  arc  interested.  Thus,  this 
general  characteristic  that  S3  has  for  identifying,  virtually  completely, 
with  actual  systems  is  specialized  to  identify  a  particular  model  with 
its  actual  counterpart.  The  result  is  an  accuracy  that  can  only  be 
matched  by  the  observed  performance  of  the  actual  system  itself. 


1.10  FILES 

Files  belong  to  the  individual  worker  programs  but  reside  on  the 
hardware  peripheral  devices  of  tlie  system.  As  mentioned  earlier,  the 
worker  programs  specify  file  references  in  terms  of  the  oi’dinal  naming 
system  already  mentioned.  Tho  files  that  are  so  referenced  are  given 
represeptati on  in  the  simulation,  model  as  part  of  the  configuration 
data. 


1.10.1  File  S  ruclurc 

The  structure  of  the  file  on  the  peripheral  device  is  defined  in 
term.,  of  blocks.  The  block  is  the  unit  of  transfer  between  tlie  device 
and  iiK'iiiory,  by  tho  assigned  transmission,  A  block  is  defined  in  terms  of 
a  data  unit  specification,  the  data  type  (alpha  or  numeric),  whether  or 
not  the  data  is  packed,  and  any  code  conversion  rcquli’cmcnts  that  might 
be  ncco.ssary. 
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1.10.2  Memory  Block 


In  the  memory,  the  block  consists  of  a  number  of  recorc^s.  The 
specification  in  the  configuration  data  for  the  number  of  records  is  called 
the  blocking  factor,  and  each  RIu/iD  or  WRITE  I/O  statement  refers  to  a 
record  v,j.l;hin  a  block  that  is  associated  with  the  file  by  its  ordinal 
name.  This  means  that  the  record  is  the  unit  of  data  processed  by  the 
simulated  worker  program  so  that  each  successive  read  simulates  the 
delivery  of  the  next  record  to  the  worker  program  for  processing. 

Records  arc  delivered  on  call  to  the  worker  program  until  all  records 
in  the  simulated  block  have  been  removed.  The  BUI'TER  statement  may  be 
used  in  the  simulated  operating  system  to  ascertain  when  this  occurs 
and  to  select  the  next  action  that  the  operating  system  undertakes  in 
order  to  refill  the  block  from  the  file. 

By  specifying  that  the  blocking  factor  is  one  record  per  block  and 
that  the  number  of  buffers  for  the  execution  of  a  particular  worker 
program  is  one,  a  buffered  execution  of  that  program  can  be  simulated. 

By  raising  the  blocking  factor  and/or  increasing  the  number  of  blocks 
assigned  to  a  particailar  ordinal  file,  varying  degrees  of  buffering  may 
be  simulated  for  a  particular  execution. 


1.10.3  Buffering  Control 

The  control  of  any  buffciing  that  is  allowed  is  properly  an  operating 
system  function.  The  simulator  machine  statements  made  available  for 
representation  of  the  operating  system  arc  clearly  sufficient  to  allow 
for  inclusion  of  any  and  all  buffering  control  techniques  that  might  be 
of  fiiterest. 


1.11  CONCLUSION 

The  method  devised  for  the  simulator  machine,  as  broadly  described 
in  this  section,  achieves  several  major  objectives  that  arc  fundamental 
to  an  accurate  and  exhaustive  simulation  of  an  actual  computer  configuration 
plus  -  operating  system.  Tliesc  objectives  are: 

A.,  The  complete  pcriormance  and  inter-connection  specifications  for 
the  hardware  of  the  system  arc  accomplished  in  terms  of  the  configuration 
data. 


B.  The  potential  load  on  the  system,  in  terms  of  the  system 
facilities  required  by  all  v.orl;ei’  progr.ams  that  may  be  run  on  it  and  the 
operating  system  required  to  run  them,  is  ropj-csented  by  means  of  coded 
program  graphs  using  sinnilatoj-  machine  statements. 
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C.  The  files  on  which  the  various  simulated  programs  operate  are 
represented  in  the  particular  simulation  model  by  moans  of  a  structure 
specification,  a  device  residence  specification,  and  a  specification  of 
the  conditions  of  buffering  allowed. 

To  make  the  application  of  S3  as  general  as  possible,  the  technique 
has  been  developed  to  provide  machine  Independence  in  the  simulated  worker 
program.  This  is  accomplished  for  INPTJ'r-OUlT’UT  by  means  of  the  ordinal 
naming  approach  for  files.  It  is  accomplished  for  CPU  utilization  by 
means  of  simulator  machine  statements  whose  operands  specify  the  amount 
of  work  to  be  done  in  terms  of  data  units,  allowing  the  simulator 
machine  to  translate  this  into  the  number  of  instructions  required  to 
accomplish  the  specified  function  according  to  the  particular  capabilities 
of  the  mainframe  under  simulation.  This  means  that  a  given  collection 
of  worker  programs,  once  prepared  for  simulati'^n,  may  bo  applied  to  an 
arbitrary  range  of  simulated  computer  systems  quite  independently  of 
the  peripheral  device  configuration,  the  number  of  memories,  CPU's  and 
transmissions  that  an  individual  system  might  include. 

1.11.1  Major  Differences 

The  major  difference  from  system  to  system  in  so  far  as  the  worker 
programs  are  concerned  is  the  operating  system  itself.  Thus,  each 
computer  system  that  is  simulated  is  associated  with  its  own  operating 
system.  A  review  of  the  woi-kcr  program  statements  made  available  by 
the  simulator  machine  will  show  that  they  are  not  only  independent  of 
the  simulated  computer  configuration  within  which  they  are  executed, 
but  are  as  well  independent  of  the  operating  system,  relying  upon  the 
logical  structure  of  the  operating  system  an.d  the  specification  of  the 
Interrupt  vector  to  accomplish  the  necessary  interface  with  the  simulated 
configuration. 

Finally,  because  we  have  separated  the  specification  of  file 
structure,  location,  and  buffering  from  the  specifications  for  both  the 
general  hardware  configuration  and  the  wox'kei’  programs  themselves,  these 
general  parameters  of  the  file  environment  of  a  particular  execution  on 
a  given  system  may  be  varied  without  any  modification  to  the  other  simula¬ 
tion  elements  being  required. 
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SECTION  II 


SIMULATION  mohel  description 


2.0  WORKER  ROUTINE  MODULE 

The  worker  routine  moiUilc  is  comprised  of  five  worker  routine 
ba.so  statements  (type  81-85)  and  18  worker  routine  statements.  The 
logic  of  the  simulation  model  is  such  that  once  worker  routines  have 
been  written,  they  do  not  require  modification  v;hcn  used  in  conjunction 
with  different  machine  configurations. 

EXAMPLE ;  The  same  set  of  worker  routines  could  be 
used  a:,  input  when  simulating  an  IBM  1401, 

.or  a  GE  625. 


2.1.1  Worker  Routine  Base  Statements 

The  worker  routine  base  statements  contain  information  that  will 
be  used  during  the  pre-simulation  phase  of  the  simulation  model. 

The  following  list  includes  information  contained  in  the  worker 
routine  base  statements. 

A.  Identification  for  simulation  and  statistical  purposes 

B.  Ordinal  file  and  real  file  identification 

C.  Memory  requirements 

D.  Incidence  of  generation 

E.  Priority 

F.  Generation  Limit 

G.  Generation  Intervals 


2.1.2  Worker  Routine  Statement  Interpretation 

The  workcj'  routine  statements  will  be  interpreted  during  the 
running  of  the  simulation  to  represent  the  program  represented  by  a 
given  woiker  routine.  The  logic  of  the  simulation  model  considers 
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worker  routines  to  bo  re-entrant,  and  further  differentiates  between 
a  passive  routine  and  active  program.  This  moans  that  a  worker 
routine  whose  first  incidence  of  arrival  is  seventy  minutes  in  a 
simulation  that  runs  only  one  hour,  will  never  be  considered  a  program. 
Although  it  has  been  residin;  the  simulation  model  for  the  length 
of  the  simulation,  it  h.-’s  not  been  introduced  into  the  active  flow  of 
programs  that  are  being  run  through  this  simulation  model. 


2.1.3  Worker  Routine  Statement  Logic 

The  logic  of  the  worker  routine  statements  provides  an  easily 
understood  and  accurate  tool  for  representing  existing  programs  as 
input  to  the  simulator.  Further,  the  range  of  these  statements  is 
sufficiently  broad  to  allow  the  representation  of  proposed  progi..ms 
which,  though  not  written,  have  definable  limits  associated  with  them. 


2.2  OPERATING  SYS'fEM  MODULE 

TVenty-eight  operating  system  statements,  plus  the  interpretative 
worker  routine  statements  are  available  to  vranscribe  the  logic  of  an 
operating  system  into  input  for  the  simulation  models. 


2.2.1  Modular  Design 

The  modular  design  of  the  simulation  roedel  is  such  that  an 
operating  system  may  be  easily  modified,  or  completely  changed  between 
run^  without  the  necessity  of  major  alterations  to  the  other  modules  of 
the  simulation  model. 


2.2.2  Operating  System  Design 

The  design  of  the  operating  system  module  will  allow  the  user  to 
literally  transcribe  thel^  logic  charts  of  an  operating  system  into 
statements  acceptable  as  input  to  ihe  simulation  model. 


2.3  CONFIGUIiATION  DATA  MODULE 

The  configuration  data  is  the  moans  by  which  the  hardware  character¬ 
istics  of  a  given  computer  may  be  entered  as  input  data  to  the  simulator. 
The  configuration  data  is  used  to  describe  the  physical  characterist j cs 
of  the  following: 
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A.  Central  Processors 

B.  Memories 

C.  Channels 

D.  Devices 

E.  Control  Units 

The  physical  relationship  between  the  listed  items  may  be  accurctcly 
described  and  the  scope  of  information  that  may  be  included  allows 
the  most  complex  computer  to  be  accurately  described.  Elementary 
computer  configurations  may  be  easily  represented  by  omitting  fields 
within  a  statement  or  entire  statements  that  arc  not  required  to  fully 
descriuc  the  configuration.  The  modularity  associated  with  the 
simulation  model  allov.’S  the  reconfiguration  of  computers  without  the 
need  to  drastically  modify  the  other  .scgmf'nts  of  the  simulation  model. 

2.4  S'^STEM  PARAMETER  MODULES 

The  system  parameters  are  the  liaison  between  the  worker  routines, 
operating  system fs)  and  configuration  data.  It  is  entirely  possible 
that  worker  routines,  operating  systom.s  and  configuration  data  may  be 
collected  as  input  by  three  .separate  groups.  It  is  essential  that  the 
pcr.-ionncl  compiling  the  thi-oc  sots  of  inputs  be  responsible  for  the 
system  paramotors.  A  listing  of  the  descriptive  information  contained 
in  the  system  pai-amcters  is  as  follows: 

A.  A  description  of  the  files,  including  their  length,  seek  time 
(if  pertinent),  position  on  a  device,  and  device  identification. 

B.  Dump  Control  information  for  debugging  a  simulation  model. 

C.  Statistical  output  control  information  for  defining  the  type 
of  statistics  to  be  gathered. 

D.  Simulation  model  control  infonnation  -  to  limit  the  length  of 
simulation  and  the  number  of  statistical  outputs  to  be  gathered  in  that 
time  period. 


2.5  PHE-SIMUIATION  MODULE 

This  portion  of  inc  model  is  responsible  for  receiving  the  input 
data  and  building  an  internal  structure  from  this  data  for  the 
simulation  cxeeulivc  al]o"irtg  highly  efficient  execution  once  the 
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actual  siaulatlon  is  started.  The  configuration  d"'  i  and  system 
parameters  are  accepted  first.  This  input  will  be  ..sed  to  sot  table 
dimensions  and  these  tables  are  located  in  memory.  The  tables  will 
contain  information  on  queues,  memory  maps,  channel  availability,  etc. 
Once  the  tables  have  boon  constructed,  the  operating  system  and 
worker  routine  statements  are  accepted  as  input  and  stored  in  their 
respective  tables.  It  is  at  this  point  that  absolute  addresses  arc 
supplied  for  all  tran-^  >r  statements.  When  all  input  data  has  been 
received  and  table  8t»..  ting  addresses  have  been  located  for  the 
simulate  crcci.tlvo,  the  rro-slritlatlon  mf'tVjlc  turiulnatob  itself  and 
turns  control  over  to  the  executive  portion. 


2.6  SIMULATION  EXECUTIVE  MODULE 

The  executive  is  responsible  for  the  actual  running  of  the 
simulation  once  all  input  has  been  accepted  and  formatted  into  the 
proper  tables.  The  operations  of  the  executive  have  been  kept  to  a 
minimum  in  an  attempt  to  make  a  simulation  run  as  efficient  (in  time 
used)  as  possible.  In ‘essence,  the  three  major  functions  of  the 
executive  are  to: 

A.  Interpret  subroutine  calls 

B.  Check  for  diagnostics 

C.  Determine  when  statistical  output  is  to  be  produced 

2.6.1  Routines  and  Subroutines 

The  routines  and  subroutines  that  are  available  to  the  executive 
are  listed  below. 

A.  Timing  routine 

B.  Continuous  Interrupt  routine 

C.  Program  Generation  routine 

D.  File/Dcvicc  Maintenance  routine 

E.  Channol/Cuntrol  Unit  Availability  routine 

F.  Dump/Tracc/Snap  Diagnostic  routines 

G.  Statistical  Analysis  routine 

H.  All  Worker  and  Operating  Systeir  statrnicnt  subroutines 

I.  A  Vector  Table  to  locate  all  sogmonls  of  the  simulation  model 
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SECTION  III 


LIMITS  AND  RESTRICTIONS 


3.0  GENERAL 

This  section  describes  the  limits  and  restrictions  of  the 
Simulation  Model  for  various  entities  that  may  be  represented  in 
a  given  simulation.  If  any  of  these  values  arc  exceeded,  a 
diagnostic  is  generated  and  the  simulation  terminated. 


3.1  CPU 

Ibe  limit  on  the  number  of  CPU's  that  may  be  represented  in 
a  simulation  is  5. 


3.2  MEMORIES 

The  limit  on  the  number  of  memories  that  may  bo  represented  in 
a  simulation  is  30.  No  more  than  10  separate  memories  may  be 
associated  with  one  CPU. 


3.3  PAGES 

The  limit  on  the  number  of  pages  that  memories  may  be  divided 
into  is  1000. 


3.4  CONTROL  UNITS 

The  limit  on  the  number  of  control  units  that  may  be  represented 
in  a  simulation  is  SO. 


3.5  CHANNELS 

The  limit  on  the  number  of  channels  that  may  be  represented  in  the 
simulation  is  50.  When  the  tally  of  ch.tnnols  rcpro.sented  in  a  given 
simulation  is  made  by  the  simulation  model,  a  value  of  one  is  associated 
with  a  selector  channel  and  a  value  of  two  is  f.ssociated  with  a  multi¬ 
plexor  channel,  'nioreforo  one  selector  ch.nnnel  and  one  multiplexor 
channel  will  equal  three  units.  The  simulation  model  always  coT.pnros 
the  mimbor  of  units  represented  by  the  different  types  of  channels 


3-1 


•gainst  the  limit  of  50.  No  more  than  20  control  units  may  be 
associated  with  one  CPU. 


3.6  DEVICES 

The  limit  on  the  different  types  of  devices  that  may  be 
represented  in  a  simulation  is  SO.  Die  limit  on  the  total  number  of 
devices  of  all  kinds  represented  in  a  simulation  is  100. 


3.7  FILES  REAL/ORDINAL 

The  limit  on  a  number  of  ordinal  files  that  may  be  represented 
in  a  simulation  is  800.  The  limit  on  the  number  of  real  files  that 
may  be  represented  in  a  simulation  is  150.  The  limit  on  a  nuiaber  of 
real  files  associated  with  one  device  in  a  simulation  is  15.  The 
final  statistics  will  include  statistics  on  21  INPUT-OUTPUT  files 
per  worker  routine. 


3.8  QUEUES 

The  limit  on  the  number  of  queues  represented  in  a  simulation 
is  30.  Thefe  may  contain  a  total  of  2000  queue  entries. 


3.9  FUNCTIONS 

The  limit  on  the  number  of  functions  that  may  be  represented  in  a 
simulation  is  100. 


3.10  AVAILABILITY  TABIH 

The  limit  on  the  number  of  entries  in  the  availability  table  is 
200.  Each  channel/control  unit  path  to  a  devide  is  considered  one  entry. 

3.11  LOAD  CLASS  ENTRY 

The  limit  on  the  number  of  load  class  entry  statements  that  may 
bo  included  in  the  configuration  data  for  a  simulation  is  15. 

3.12  RUN  CLASS  ENTRY 

The  limit  on  the  number  of  run  class  entry  statements  th.at  i  ;y  be 
included  in  the  configuration  data  for  a  simulation  is  5. 
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3.13  SIMULW'ION  CONTROL 


If,  when  multiplied  together,  the  two  fields  of  the  simulation 
control  statement  (S/P  card  code  31)  produce  a  value  greater  than 
24  hours  (1440  minutes)  the  simulation  is  terminated. 


3.14  INTERRUPT 

The  limit  on  the  number  of  interrupts  that  may  be  associated 
with  each  CPU  being  represented  in  a  slmulntion  is  20.  The  first  8 
of  these  20  int'~  rupts  arc  pre-assic.ncd  and  must  reference  addresses 
within  the  operating  system. 


3.15  W/R  STATEMENTS 

Die  limit  on  the  number  of  worker  routine  statements  that  may  be 
repre.sentcd  in  a  simulation  is  15,000.  Any  number  of  operating  systems, 
primary  worker  routiner  or  worker  routines  may  be  represented  within 
this  limit. 


3.15.1  W/R  Programs 

The  limit  of  the  number  of  programs  that  may  bo  active  within 
the  simulation  at  a  given  time  is  300. 


2.15.2  W/R  Inputs/Outputs 

The  limit  on  the  number  of  INPUT-OUTPUT  activities  that  may  be  in 
progrcb.s  coincidentally  is  900. 


3.16  SWITCHES 

The  limit  on  the  numl>er  of  switches  that  may  be  referenced  in  a 
simulation  is  200.  Switches  numbered  101-200  ore  considered  to  l>c  global 
and  m.Ty  be  use<l  as  liaison  between  operating  systems.  Each  of  the  5 
CPU's  permitted  in  a  simulation  m.ay  have  20  local  switches  (1-20) 
associated  with  it. 


3.17  MARK 

The  limit  on  the  n«'mber  of  Bark  counters  that  tay  b**  occurAtl  a  ted 
dtiring  a  Slmulaiion  is  10.  Tixese  a.iik  counters  ais-  refer<  need  by  tlie 
second  parameter  of  the  cor  put  c  wlalcrent.  Only  njK-r.i  t  i  n;.  sv-^-tens 
or  nrim.ary  worker  roullne.s  rsy  make  use  of  this  far  il  tty. 
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SECTION  IV 


DEVICE  DEFINITION  AND  CONFICUnATION  DESCRIPTIONS 


4.0  GENERAL 

IliiB  soction  is  a  detailed  device  definition  and  configuration 
doacriptlon  for  the  syaten.  It  includes  keypunch  instructions  and 
sawple  configuration  cards. 


NOTE 


All  fields  which  are  not  used  mist  be  xero  filled. 
No  olph.'i  characters  may  be  punched  in  these  cards 
except  in  columns  7C-80. 


4.1  CPU  DEFINITION  CARO  ill 


4.1.1  Card  Code  01 

4.1.2  CPU  Identiflcntion  Number 

This  field  nay  contain  any  four  digit  nueil>er  from  0001  to  9999. 

4.1.3  CPU  Logic.il  Data  Unit 

The  primary  unit  of  da»a  processed  b>  this  CPU.  For  example,  in 
the  IBM  System  300  the  Ix^gical  Data  Unit  is  the  PfTE. 


4.1.4  Decimal  Arithnctic  Tines 

Ihcsc  fields  must  be  filled  if  the  CPU  being  defined  is  capable  of 
performing  base  10  arithnctic. 

A.  Number  of  Decimal  Digits 

When  dclcmlnlng  the  tire  to  perfojr.  a  decimal  arithmetic  operation 
the  number  of  digits  operated  up«m  rust  be  supplied. 


B.  Decimnl  Add  Time 


\v 


The  time,  expressed  in  microseconds,  to  add  two  fields  of  ihe 
length  given  above. 

C.  Decimal  Multiply  Time 

The  time,  expressed  in  microseconds,  to  multiply  two  fields 
of  the  length  given  above. 

D.  Oecimnl  Divide  Time 

The  tine,  expressed  in  microseconds,  to  divide  one  number 
of  the  length  given  above  into  a  number  twice  the  length  above 
giving  a  quotient  of  length  above,  and  a  reta.'iinder  of  the-  same  length. 


4.1.5  Fixed  Foii’l  Arithmetic  Time 

These  fields  must  be  filled  if  the  CPU  being  defined  is  capable  of 
performing  base  2  arithmetic. 

A.  Fixed  Point  Add  Time 

The  time,  expressed  in  microseconds,  to  add  two  field.s 
of  the  standard  length,  taking  both  fields  from  m.nin  slora„c  and 
returning  the  result  to  storage,  Including  rll  load  and  store 
operations. 

B.  Fixed  Point  Multiply  Time 

The  time,  expressed  in  microseconds,  to  multiply  two  fields 
of  the  standard  length,  taking  both  firld.s  from  r.i.nin  storage  and 
returning  the  product  to  storage, 

C.  Fi.xed  Point  Divide  Time 

The  tinic,  e.xpresscd  in  m .cru;;ccoiuls ,  to  divide  one  standard 
length  field  by  another,  taking  both  fie'U.-  fron  storage  nr.H  leturning 
the  quotient  or  the  ren.-tlnder  to  slor.tgo. 


4.1.6  Floating  Pninl  An  ttii-,’.»'t  ic  Tir  t  s 

Thc.sf  fields  mist  l>e  fillf-ci  if  the  CPI'  bv  1 114  detinfd  is  capable 
of  per  fore,  in"  float  in,;  point  a  r  j  t  hue  i  i<  . 
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A.  Floating  Point  Add  Time 


The  time,  expressed  in  microseconds,  to  add  two  single 
precision  floating  point  numbers,  including  pre  and  post-normalization 
If  required  or  standard,  Ir'iii.g  both  fields  from  storage  and  returning 
the  result  to  storage. 


B.  Floating  Point  Multiply  Time 


The  time,  expressed  in  microseconds,  to  multiply  two  single 
precision  floating  point  nutr.  ers,  taking  both  fields  from  storage 
and  returning  the  product  to  storage. 

C.  Floating  Poin'  Divide  Time 


The-  time,  expressed  in  microseconds,  to  divide  one  single 
precision  floating  point  number  into  another,  taking  both  fields  from 
storage  and  returning  the  quotient  to  storage. 


4.1.7  System  ID 

This  field  nay  bi  used  for  card  ident  fication  or  any  user 
function.  It  is  not  checked  or  used  by  this  system. 


NOTi: 


The  limit  on  the  number  of  CPU's  that  may  be  represented 
•'  in  a  simulatic  is  5. 

4.2  CPU  DKFINITIOX  CARD  02 

4.2.1  C.ard  Code  02 


4.2.2  CPU  Identification  Number 

This  iiolt'  may  contain  any  four  digit  iiumbcr  from  0001  to  9999. 

4.2.3  Instruction  bengtii 

The  .average  irsiruetion  length  expressed  in  bogica]  Data  Units. 
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4.2.4  Decimal  Digits  I’cr  Ix>gicaJ  Data  Unit 


ITie  number  of  decimal  digits  which  can  be  placed  in  a  Logical 
Data  Unjt;  c.g.,  two  decimal  digits  can  be  placed  in  ne  BYTE  in 
the  IBM-360. 


4.2.5  Characters  Per  Logical  Data  Unit 

The  number  of  characters  which  can  bo  placed  in  a  Logical  Data 
Unit;  e.g.,  six  alphanoumeric  characters  can  be  placed  in  a  36-bit 
word  in  the  UNIVAC1108. 


4.2.6  Move  Time  Per  Logical  Data  Unit 

The  time,  expressed  in  inicror.cconds,  to  move  one  Logical  Data 

Unit . 


4.2.7  Move  and  Edit  Time  Per  Character 

The  time,  expressed  in  microseconds,  to  move  and  edit  a  single 
character. 


4.2.8  Fixed  Point  Table 

The  Fixed  Point  Table  should  be  completed  if  the  CPU  being 
described  in  capable  of  base  2  arithmetic.  ’ 

A.  Entries 

Each  entry  iiv  the  fixed  point  conversion  table  has  two 
values  associated  with  it.  The  first  value  is  a  number  of  Logical 
Data  Units;  the  second  is  a  number  of  decimal  digits.  The  purpose 
of  this  tabic  is  to  describe  the  size  of  the  fixed  point  aritlimcLic 
which  can  be  manipulated  by  this  CPU.  For  example,  the  IBM  360  is 
capable  of  doing  half  word,  full  word,  and  double  word  fixed  point 
arithmetic.  To  descriljc  iialf  word  arithmetic,  a.ssuming  a  BYTE  is 
the  ijogical  Data  Unit,  the  entry  would  be  [~ 02  |  04  j  .  This  means  that 
using  two  Logical  Pal  a  Units  (BYTES),  the  System  360  can  represent  any 
4-digjt  dccim.al  number  expressed  in  base  2.  This  value  is  arj’ivcd 
at  by  taking: 
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Two  BYTES  X  8  bits  per  BYTE  =  18  bits 


16  bits  -  1  sign  bit  =  15  bits 
15 

2  -  1  =  32767-^^.  which,  rounding  down,  allows 

expression  of  4  decimal  digits. 


The  next  entry  in  this  table  would  bo  Qf4  09 


full  word  fixed  point  operations  in  Systcni  360. 


which  describes 


4.2.9  Floating  Point  Table 


The  Floating  Point  Table  should  be  completed  if  the  CPU  being 
described  is  capable  of  floating  point  arithmetic. 

A.  Entries 


Each  entry  in  the  floating  point  conversion  table  has  two 
values  associated  with  it.  The  first  value  is  a  number  of  Logical 
Data  Units;  the  second  is  a  number  of  decimal  digits.  The  purpose 
cf  this  lable  is  to  describe  the  size  of  the  floating  point  fields 
which  can  be  manipulated  by  this  CPU.  For  example,  System  360  is 
capable  of  doing  short  and  long  precision  floating  point  arithmetic. 
To  describe  short  precision  floating  point,  assuming  a  BYTE  is  the 


Logical  Data  Unit,  the  table  enti-y  would  be 


07 


This  means 


that  using  4  Logical  Data  Units  (BYTES),  System  360  can  represent  a 
floating  point  number  to  seven  decimal  digits  of  precision.  This 
value  is  arrived  at  by  taking  a  32-bit  word  (4  BYTES)  less  a  1  bit 
for  characteristic  sign,  less  a  7-bit  characteristic,  leaving  a 
24-bit  fraction. 


1 


16,777,215  which,  rounding  down  permits 
7  positions  of  precision. 


The  next  entry  in  this  table  would  be  f  08 
double  precision  floating  point  arithpietic. 


nz] 


which  describe.s 


4.2.10  Gibson  Mix  Factor 

This  field  contains  a  value  that  represents  an  average  mix  of 
instructions  for  a  commericnl  application.  This  value  will  bo  applied 
to  the  number  of  instructions  associated  with  the  COMPUTE  statement  to 
produce  a  simulated  time  value. 
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4.2.11  System  ID 


This  field  may  be  used  for  card  identification  or  any  user 
function.  It  is  not  checked  or  used  by  this  system. 

4.3  MEMORY  DEFINITION  CARD  03 

4.3.1  Card  Code  03 

4.3.2  Memory  ID 

This  field  may  contain  any  4  digit  number  from  0001  to  9999. 

4.3.3  Memory  Access  Unit 

This  entry  describes  the  number  of  usable  bits  (not  including 
parity  or  other  check  bits)  which  are  accessed  by  a  single  memory 
reference.  For  example,  the  IBM  1401  memory  access  unit  is  6  bits. 

NOTE 

Neither  the  word  mark  nor  the  parity  bit  is  counted. 

4.3>4  Memory  Cycle  Time 

Memory  Cycle  Time  is  the  minimum  time,  expressed  in  microseconds, 
between  the  start  of  a  memory  acccs.s  and  the  start  of  the  next  memory 
access  to  the  same  memory  unit. 

4.3.5  Memory  Access  Time 

Mcmc'v  Access  Time  is  the  minimum  time,  expressed  in  microseconds, 
between  the  start  of  a  memory  access  and  the  availability  of  the  data  accessed. 

4.3.6  Memory  Size  in  Memory  Units 

Memory  Size  is  the  number  cf  memory  access  units  in  this  memory. 
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NOlTi: 


The  Memory  Access  Unit  is  not  necessarily  the 
same  size  as  the  Logical  Data  Unit.  For  example, 
in  the  IBM  System  360  Model  30  the  Memory  Access 
Unit  is  the  BYTE,  and  the  Logical  Data  Unit  is 
also  the  BYH;.  However,  in  the  Model  40,  the 
Memory  Access  Unit  is  the  half  word  (2  BYTES)  while 
the  Logical  Data  Unit  is  still  the  BYTE. 


4.3.7  Pagi^  Size  in  Memory  Units 

Page  Size  is  the  Unit  in  which  memory  is  allocated,  usually  the 
size  of  the  Memory-Protect  Bounds. 

NOTE 

The  limit  on  the  number  of  memories  that  may  bo 
repre.sented  in  a  simulation  is  30.  Not  more  than 
10  memories  may  be  associated  with  one  CPU. 

The  limit  on  the  number  of  p^ges  that  may  be  repre¬ 
sented  in  a  given  simulation  i.s  1000. 


4.4  CHANNEL  DEFINITION  CARD  04 


4.4.1  Card  Code  04 


4.4,2  Channel  ID 

Tliis  field  may  contain  any  4  digit  number  from  0001  to  9999. 


4.4.3  Channel  Type 

This  field  is  used  to  describe  the  channel  a.s  either  a  s'’''eto” 
or  a  multiplexor  channel .  A  selector  channel  is  capable  of  operating 
one  and  only  one  devide  at  a  time.  A  multiplexor  channel  i.s  capable 
of  operating  moio  than  one  device  at  a  time. 
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4.4.4  Type  Codes 

1  =  Selector  Channel 

2  =  Multiplexor  Channel 


4.4.5  Maximum  Selector  or  Burst  Mode  Transfer  Rate 

If  the  channel  being  described  is  a  selector  channel,  enter 
the  maximum  transfer  rate  in  characters  per  second. 

If  the  channel  being  described  is  a  multiplexor  channel  which 
is  capable  of  a  greater  transfer  rate  when  operating  a  single  device 
(Burst  Mode)  than  when  operating  multiple  devices,  enter  the  maximum 
transfer  rate  when  operating  a  single  device. 


4.4.6  Selector  or  Burst  Mode  Interference  Rate 

If  this  channel  shares  CPU  time  with  the  main  processor,  enter  the  per¬ 
cent  of  CPU  time  lost  per  1000  CPS  transfer  rate  for  this  channel. 

If  the  Interference  Rate  is  not  a  linear  function,  choose  the  average 
load  point  to  determine  this  value. 


4.4.7  Maximum  Multiplexor  Transfer  Rate 

This  entry  should  be  supplied  only  if  the  channel  being  described 
is  a  Multiplexor  Channel.  Enter  the  Maximum  Transfer  Rate  (CPS)  when 
this  channel  is  operating  in  multiplexor  mode. 


4.4.8  Multiplexor  Interference  Rate 

Enter  the  Interference  Rate  for  this  channel  when  it  is  operating 
in  multiplexor  mode  as  shown  above. 


4.4.9  System  ID 

This  field  may  bo  used  for  card  identification  or  any  other  user 
function.  It  is  not  checked  or  used  by  this  system. 
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NOTE 


The  limit  on  the  number  of  channels  that  may  be 
represented  in  a  simulation  is  50.  No  more  than 
20  channels  may  be  associated  with  one  C?U.  A 
multiplexor  channel  counts  for  two  when  a  tally  of 
channels  is  made  against  the  limit. 


4.5  DEVICE  DEFINITION  CARD  05 


4.5.1  Card  Code  05 


4.5.2  Device  Identification  Number 

This  field  may  contain  any  4  digit  number  from  0001  to  9999. 


4.5.3  Device  Type 

This  field  is  used  to  describe  the  device  as  one  of  the 
following: 

A.  Unit  Rccoid 

B.  Tape 

C.  Random  Access 

D.  Other 


4.5.4  Data  Transfer  Rate  (All  Devices) 

The  Data  Transfer  Rate  is  the  rate  at  which  the  device  is 
capable  of  receiving  or  transmitting  data.' 

4.5.5  Transfer  Width  (All  Devices) 

The  Transfer  Width  is  the  number  of  bits  which  are  transferred 
as  a  unit  to  this  device,  excluding  parity  or  other  chock  hits.  For 
example,  a  7-tr..ck  tape  has  a  width  of  6  bits,  a  9-track  tape  has  a 
width  of  8  bits.  Note  however,  if  the  device  or  control  unit  translates 
the  data,  such  as  a  7-track  tape  drive  on  System  300  using  the  translate 
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feature,  into  a  greater  or  lesser  number  of  bits,  the  device  should  be 
described  in  terms  of  the  number  of  bits  accepted,  not  the  number  of 
bits  recorded,  i.e.,  a  7-track  tape  using  the  translate  feature  would 
be  defined  with  a  width  of  8  bits.  A  7-track  tape  using  data  conversion 
would  be  defined  with  a  width  of  6  bits. 


4.5.6  START/STOP  Time  (Any  Device) 

START/STOP  Time  is  the  total  time,  expressed  in  microseconds, 
over  and  above  the  transfer  time  which  the  device  requires  to  be 
activated  and  deactivated.  For  example,  a  System  360  2400  9-track 
model  1  tape  drive  has  a  START/STOP  time  of  16,000  microseconds. 

NOTE 


During  START/STQP  time,  the  channel,  control  unit, 
and  device  arc  all  busy. 


4.5.7  Device  T'me 

Unit  Record  Device  Time  is  the  time,  expressed  in  microseconds, 
during  which  a  BUFFERED  unit  record  device  is  busy  after  the  channel 
is  free. 


NOTE 

During  unit  record  device  time,  the  channel  is 
considered  free  after  the  data  transfer  is  completed, 
even  though  the  device  and  control  unit  are  still 
busy. 

4.5.8  Tape  Rewind  Time  (Tape  Devices  Only) 

Tape  Rewind  Time  is  the  amount  of  time,  expressed  in  hundredths 
of  a  minute  required  to  rewind  a  tape. 

NOTE 

During  rewind  time  the  device  i:  considered  to  be  busy, 
but  the  control  unit  and  channel  arc  free. 
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4.5.9  Time  Limit  Before  Invoking  a  Penalty  (Any  device) 

Certain  devices  are  capable  of  providing  faster  I/O  times  than 
normal  if  the  time  between  I/O  operations  docs  not  exceed  a  certain 
limit.  For  the  purpose  of  simulation,  we  consider  the  fastest 
possible  tine,  the  normal  time.  Then,  if  the  time  limit  entered  in 
this  field  :.s  exceeded  between  I/O  calls  to  this  device,  the  time 
penalty  is  added  to  the  normal  I/O  time. 


4.5.10  Penalty  Time 

The  time,  expressed  in  microseconds,  which  is  to  be  added  to 
the  normal  I/O  time  if  no  I/O  call  to  this  device  has  occurred  during 
the  time  limit  describe  1  above. 

Penalty  Time  is  added  to  the  channel,  control  unit,  and  device 

time. 


4.5.11  Form  Advance  Time 

This  field  may  be  used  when  a  printer  is  being  described. 

The  START/STOP  time  in  the  sixth  field  is  normally  used  to  rei.»‘esent 
a  single  line  advance.  If  it  is  desiz'ed  to  represent  multiple  line 
form  advance,  the  time  in  microseconds  must  be  placed  in  this  field. 

NOTE 

The  limit  on  the  number  of  devices  that  may  be  represented 
in  a  simulation  is  100. 


4.6  CPU  CONFIGURATION  CARD  06 

4.6.1  Card  Code  06 

4.6.2  CPU  Number 

When  configuring  a  system,  there  will  be  one  CPU  configuration 
card  per  CPU  in  the  system.  The  Cl’U  cards  must  be  numbered  scr,ucntiBlly 
in  this  field  from  0001  to  9990. 
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4.6.3  CPU  Identification  Number 


4  ■». 


Ibi*;  field  must  contain  the  CPU  Identification  Number  on  the 
CPU  definition  card  for  this  CPU. 

4.7  MEMORY  (XWFICURATION  CARD  fil 

4.7.1  Card  Code  07 


4.7.2  Memory  Number 

When  configuring  a  sy.icn  there  will  be  one  memory  configuration 
card  per  memory  in  the  system.  The  memory  cards  must  be  numbered 
sequentially  in  this  field  from  0D01  to  9999. 


4.7.3  Memory  Identification  Number 

This  field  must  contain  the  memory  identification  number  from 
the  memory  definition  card  which  defines  this  memory. 


4.7.4  CPU's  Associated  with  this  Memory 

The  CPU  number  (not  Identification  Number)  of  each  CPU  which 
can  reference  this  memory. 


4.7.5  Channel  Configuration  Card  08 

4.7.6  Card  Code  08 

4.7.7  Channel  Number 

When  configuring  a  system  there  will  be  one  channel  configuration 
card  per  channel  in  the  system.  The  channel  cards  must  be  miabcred 
sequentially  in  this  field  from  0001  to  9999. 

4.7.8  Chan, tel  Identification  Number 

This  field  must  contain  the  channel  idvnt i f iention  number  from 
the  chann:l  definition  card  which  defines  this  channel. 
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4.7.9  CPU's  Associated  with  this  Channel 


TIm  CPU  iMnbor  (not  Identification  Number)  of  each  CPU  which 
can  reference  this  channel . 


4.8  OOHTROL  UNIT  CONFIGURATION  CARD  09 


4.8.1  Card  Code  09 


4.8.2  Control  Unit  Number 

Vhen  configuring  a  system  there  will  be  one  control  unit 
configuration  card  per  control  unit  in  the  system.  The  control  unit 
cards  must  be  numbered  sequentially  in  this  field  from  0001  -  9999. 


4.8.3  I/O  code 

The  1/0  code  specified  the  possible  directions  of  Data  flow 
through  this  control  unit. 

1  a  Input  only 
S  a  Output  only 
3  a  Input  and  Output 

4.8.4  Channels  Associated  with  this  Control  Unit 

The  channel  number  (not  luentif lest  ion  Number)  of  each  channel 
which  can  address  thi*^  control  unit. 

WOTg 

A  control  unit  must  be  assumed  for  each  channel,  even 
though  one  doca  not  exist  in  a  real  configuration. 

Type  9  and  type  10  statements  a/c  used  in  conjunction 
to  build  on  ^vailabtl  it)-  table.  The  maximum  nunts.'r 
of  entries  permitted  in  this  table  is  200.  Each  control 
wnit/channri  p.-»th  to  a  device  Is  considered  one  entry. 
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4.9  DEVICE  CONFICUKATION  CARD  10 


4.9.1  Cnrd  Code  10 


4.9.2  i>evicc  Number 

When  configuring  a  eyatem  there  will  be  one  device  configuration 
card  per  device  in  the  aysten.  Tltc  device  cat  ta  must  bo  numbered  in 
this  field  from  0P^il  to  9999. 


4.9.3  Device  Identification  Kuint>cr 

This  field  must  contain  the  device  identification  number  from  the 
device  definition  card  which  defines  this  device. 


4.9.4  Seizing  Code 

Tiiis  code  is  used  to  specify  whether  this  device  may  be  seized 
by  a  worker  routine  or  not. 

1  r  Seizable 

2  *  Kon-Seizablo 


4.9.S  Control  Units  Associated  with  this  Device 

Ihc  control  unit  number  (not  Identification  number)  of  each  control 
unit  which  can  address  this  device. 

NOTE 

A  control  unit  must  bc'  assumed,  and  named,  even 
though  one  docs  not  exist  in  c  rca'  conflguratitmt. 

4.10  TO-ITIOM  TAB14;  CARO  11 

4.10.1  Card  Cod.’  11 
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4.10.2  To-From  Table: 

A  To-From  Table  should  be  filled  out  whenever  there  is  more 
than  one  file  resident  on  a  device.  Each  row  and  column  in  the 
table  is  identified  by  a  relative  file  location  as  shown  below'. 


TO 


TRm 


File  1 

File  2 

File  3 

File  1 

13 

47 

12 

File  2 

07 

64 

19 

File  3 

87 

41 

93 

The  average  time  to  go  from  one  file  to  another  on  the  same 
device  is  entered  into  the  table.  For  example,  to  go  from  relative 
file  2  to  relative  file  3  on  the  device  specified  above  would  take 
41  milliseconds  in  addition  to  the  normal  I/O  time. 


4.10.3  Device  Number 

Ihls  file  identifies  the  device  with  w.''.ieu  this  To-From  Table 
is  to  be  associated. 


4.10.4  To  Row 

This  entry  specifies  which  row  of  the  To-From  Table  this  card 
defines. 


4.10.5  Array  Dimension 

This  field  specifies  the  number  of  rows  and  columns  in  this 
table. 


4.10.6  Seek  Times  in  Milliseconds 

These  fields  contain  the  To-From  Table  entries  in  milliseconds. 
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4.11  FUNCTION  TABIJE  CARD  12 


4.11.1  Card  Codfj  12 


4.11.2  Functions 

Functions  are  generalized  input/output  expressions  which  are 
used  to  simulate  rare  Input/output  operations.  A  function  is  defined 
by  the  amounts  of  time,  expressed  in  microseconds,  the  channel  control 
unit,  and  device  are  busy. 


4.11.3  Function  Number 

The  number  by  which  this  function  is  identified  in  a  function 
statement. 


4.11.4  Channel  Time 

The  time  the  channel  is  busy  executing  this  operation. 

4.11.5  Control  Unit  Time 

The  time  the  Control  Unit  is  busy  executing  this  operation. 

4.11.6  Device  Time 

The  time  the  Device  is  busy  executing  this  operation. 

4.11.7  Device  Number 

The  number  (not  Identification  Number)  of  the  device  on  which 
this  I/O  function  is  to  be  perfomed. 

NOTE 

The  limit  on  the  number  of  functions  that  may  be 
represented  in  a  simulation  is  100. 
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SBCnON  V 


SYSTEM  PARAMETERS  AND  DESCRIPTIONS 


5.0  TO  FROM  TABLE  STATEMENT 

This  system  parameter  statement  is  used  to  construct  TO-FROM  tables 
for  each  device  represented  in  a  simulation.  The  values  Inserted  into 
these  tables  represent  the  seek  time  required  to  access  a  particular 
file  on  a  device  relative  to  the  last  file  accessed  on  that  device. 


5.1.1  Card  Code  21 


5.1.2  Device  Number 

This  field  may  contain  any  four  digit  number  from  0001  to  9999. 

5.1.3  TO  ROW 

This  twt'  digit  field  must  contain  the  number  of  the  TO  ROW  to  which 
the  following  seek  times  pertain. 


5.1.4  Array  Dimension 

This  two  digit  field  must  contain  the  size  of  the  table  required  to 
contain  the  number  of  files  being  represente’d  on  a  given  device. 


5.1.5  Relative  File  Number 

These  fifteen  fields  of  five  digits  are  used  to  represent  the  seek 
time  from  one  file  to  another  on  a  given  device. 


NOTE 

A.  A  TO-’FROU  STATEMENT  must  exist  for  every  device  being 
represented  even  though  only  one  file  is  associated 
with  that  device. 

B.  The  number  of  TO'FROM  TABLE  TIME  entries  must  equal  the 
value  in  the  ARRAY  DIMENSION  field. 

C.  No  more  than  15  files  may  be  associated  v/i*\  a  device. 

D.  The  seek  time  associated  with  the  relative  files  must 
be  in  milliseconds. 
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6.2  FUNCTION  STATEMENT 


5.2.1  Card  Code  22 


5.2.2  Function  Number 

This  field  may  contain  any  four  digit  number  from  0001  to  0999.  It 
is  associated  with  the  corresponding  number  in  the  first  parameter  of  a 
FUNCTION  statement  as  used  by  an  operating  system. 


5.2.3  Channel  Time 

This  seven  digit  field  represents  channel  usage  time  in  microseconds. 
There  is  an  assumed  decimal  point  after  the  fourth  digit. 


5.2.4  Control  Unit  Time 

This  seven  digit  field  represents  control  unit  usage  time  in  micro¬ 
seconds.  There  is  an  assumed  decimal  point  after  the  fourth  digit. 


5.2.5  Device  Time 

This  seven  digit  field  represents  device  usage  time  in  microseconds. 
There  is  an  assumed  decimal  point  after  the  fourth  digit. 


5.2.6  Device  Number 

This  four  digit  field  represents  the  device  (by  number)  to  be  used 
by  the  function  statement  named  in  the  second  field. 

5.3.  QUEUE  STATEMENT 

5.3.1  Card  Code  23 

5.3.2  Queue  Number 

This  field  may  contain  any  four  digit  number  from  OOCl  to  9999, 


5.3.3  Haxirum  Number  Entries 

This  four  digit  field  represents  the  maxinum  number  of  entries  per¬ 
mitted  in  a  given  queue. 
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5.3.4  Queueing  Method 

This  two  digit  field  ropi'csents  the  queueing  method  to  be  used  by 
the  simulation  model  when  inserting  and  removing  entries. 

1  B  FIFO  (first  in,  first  out) 

2  B  LIFO  (last  in,  first  out) 

3  B  Priority  (a  parameter  of  the  GENERATE  statement  or  the 

SYSTEM  DEFINITION  statement) 


5.3.5  Queue  Control 

This  two  digit  field  represents  the  type  of  transaction  item  being 
stored  in  a  given  queue. 

1  =  AT  (available  transaction) 

2  B  lOT  (I/O  transaction) 


NOTE 

If  the  queue  control  parameter  of  this  statement  does 
not  match  the  first  parameter  of  the  PLACE  and  SELECT 
statements,  an  error  message  will  be  generated  and  the 
simulation  will  be  tenidmited. 

The  limit  on  the  number  of  queues  in  a  simulation  is  30. 

There  may  be  a  maximum  of  2000  queue  entries  at  any  given 
time  during  a  simulation. 

5.4  LOAD  CLASS  STATEMB«T 

This  system  parameter  is  used  to  designate  which  of  the  central 
processors  being  represented  arc  able  to  load  a  given  worker  routine.  The 
information  contained  in  the  LOAD  CLASS  statement  will  be  used  in  conjunction 
with  information  from  the  RUN  CLASS  statement  (Card  Code  25)  and  the  PROGRAM 
DISlYtlBUTION  statement  (Card  Code  28)  to  determine  where  routines  may  bo 
loaded  and,  once  loaded,  under  which  central  processor  they  will  bo  run* 


5.4.1  Card  Code  24 
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5.4.2  Load  Class  Entry  Number 

This  field  specified  the  number  of  this  LOAD  CLASS  statement. 
There  may  be  a  total  of  fifteen  LOAD  CLASS  statements  associated  with 
a  given  simulation. 


5.4.3  CPU  1  Through  5 

These  five  fields  of  two  digits  each  specify,  for  a  given  LOAD  C1AS8, 
which  central  processors  may  load  a  worker  routine.  The  five  fields 
allow  the  maximum  number  of  central  processors  permitted  in  a  simulation 
to  be  repre  ..ited. 


Bxanple  i: 

consider  a  configuration  with  three  CPU's  associated  with 
one  memory  and  agroup  of  worker  routines  that  can  be  run 
under  the  control  of  any  of  the  central  processors. 

One  LOAD  CLASS  statement  will  be  required  and  will  appear 
as  follows : 

CARD  CODE  -  24 
LC3  #  =1 

CPU  =1 

CPU  #  =2 

(PU  #  «  3 


Example  2: 

Consider  a  configuration  with  CPU  1  associated  with  Uomory  1 
which  reprosentsa  7094  and  CPU  2  associated  with  Memory  2 
which  represents  a  1401. 

Two  LOAD  CLASS  cards  will  be  required  and  will  appear  as 
follows: 


CARD  CODE  >  24 
LCE  #  «  I 

CPU  #  -  I 


CARD  CODE  «  24 
LCE  #  -  a 

CPU  «  -  2 
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Tills  systoM  psrsnciors  mist  contsln  st  least  one  LOAD  CLASS 
ststCMent. 

The  Halt  on  the  number  of  load  class  entries  in  a  slmilation 
is  15. 


5.5  KIM  CLASS  STATSUBTr 

This  systea  parameter  Indicates  to  the  simulator  vfalch  central  pro¬ 
cessor  can  run  a  progroa  that  tias  been  loaded  into  a  given  aoaory. 


5.5.1  Card  Code  25 


5.5.2  RIM  CLASS  Mitry  Number 

This  four  digit  field  identified  each  of  the  RUN  CLASS  entries  that 
nay  exist  in  a  given  siaulatlon. 


5.5.3  CPU  1  through  5 

These  five  fieldc  of  two  digits  will  associate  central  processors 
with  the  RUN  CLASS  BiTRY  #. 


Referring  to  BXAIPLB-2  in  the  LOAD  CLASS  stateaent,  the 
following  two  RUN  CLASS  statoaents  will  be  required. 

CARD  CODE  »  25  CARD  OOMK  -  25 
RCB  #  -  1  RCS  f  -  2 
CPU  #  -  1  CPU  #  •  2 


These  stateaonts  will,  in  effect,  describe  the  configuration 
being  simulated.  They  will  indicate,  to  t!.?*  Slaulator  Model, 
the  following: 

e.  A  Vorker  routine  loaded  by  CPU  fl  can  be  run  by  CPU  fl 
or  CPU  #2  (if  logic  permits). 

b.  A  Worker  routine  loaded  by  CPU  #2  can  be  run  by  CPU  f  1 
or  CPU  P2  (if  logic  peraita). 

e.  A  Worker  routine  loaded  by  CPU  #3  aust  be  run  by  CPU  W3. 
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NOTE 


Tho  systen  parameters  mist  contain  at  least  one  RUN  CLASS 
statement. 

The  limit  on  tho  number  of  run  class  entries  in  a  simulation 
is  5. 


5.6  FILE  DESCRIPTION  STATEM^MT 


5.6.1  Card  Code  26 


5.6.2  Real  Pile  Number 

This  field  contains  the  real  file  number  and  may  be  any  four  digit 
number  between  0001  and  9999. 


5.6.3  Device  Number 

This  frur  digit  field  specified  the  device  with  which  the  real  file 
is  associa.  'd. 


5.6.4  Relative  Location 

'  This  two  digit  field  specified  the  relative  location  on  a  device  of 
the  file  being  described.  For  exajqjlc.  if  real  file  8  and  9  were  tho 
only  two  files  on  a  disc,  their  relative  positions  on  that  device  would 
be  1  and  3,  if  there  is  only  one  file  per  device,  a  1  must  bo  inserted 
into  thlt  field. 


5.6.5  Buffer  Length 

Thlfc  seven  digit  field  ryccifies  a  file  buffer  length  in  charact<}ra 


5.6.6  Records  Per  Buffer 

This  four  digit  field  specifies  th*'  ntei|>i>r  of  record*  contained 
in  one  of  a  files  buffers. 

5.8.7  NiaeVr  of  Duffers  in  File 

This  seven  digit  fi«'ld  the  mnV  r  of  buffers  tor  V  -eis*) 

in  a  file,  it  is  m  essence  a  dvr-crjjt* of  ihe  f|)t»  length. 
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There  must  be  a  file  description  statement  for  each  file 
referenced  dui'ing  a  simulation.  The  limit  on  the  number 
of  real  files  that  may  bo  represented  in  a  simulation  is 
150. 


5.7  SYSTEM  DEFINITION  STATEMENT 


5.7.1  Card  Code  27 


5.7.2  Standard  Priority 

This  four  digit  field  specifies  the  priority  number  to  be  associated 
with  all  worker  routines  that  have  not  been  assigned  a  priority  by  their 
GENQIATE  statement.  Since  01  is  reserved  for  at  least  one  operating 
system,  this  number  mu?t  be  in  the  range  02~99. 


5.7.3  Memory  Allocation  Scheme 


This  three  digit  field  represents  the  manner  in  which  the  Simulation 
Model  will  allocate  memory. 


1  =  contiguous  instruction  pages,  non-contiguous  data  and  i/0  pages 

2  =  non-contiguous  instruction  pages,  contiguous  data  and  I/O  pages 

3  =  contiguous  Instruction  pages,  contiguous  but  separate  data 

and  I/O  pages. 

4  =  contiguous  instruction  pages,  data  and  I/O  pages, 

5  =  non-contiguous  instruction  pages,  non-contiguous  data  and 

I/O  pages. 


5,7,4  CPU-1  0/S  Program  Number 

This  four  digit  field  specifies  to  the  simulation  model  the  number 
of  the  operating  system  to  be  associated  with  CPU-1. 

The  following  four  fields  in  this  statement  arc  used  for  the  same 
purpose,  depending  upon  the  number  of  CPU’s  being  represented  in  a  given 
simulation. 
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The  limit  of  CPU's  that  can  be  represented  in  a  given 
simulation  is  five. 


5.8  PROGIUVM  DISTRIBUTION  STATEMENT 

This  system  parameter  indicates  (in  a  multi-CPU  configuration) 
which  central  processor  may  receive  a  worker  routine  and  which  central 
processor (s)  may  run  that  worker  routine. 


5.8.1  Card  Code  28 

5.8.2  Program  Number 

This  four  digit  field  ident.  es  the  worker  routine  to  be  associated 
with  the  information  in  the  rest  of  this  statement. 


5.8,3  Receiving  CPU 

This  three  digit  field  indicates  the  Central  processor  that  will 
receive  the  worker  routine  associated  with  this  statement. 


5.8.4  Load  Class  Entry  Number 

This  three  digit  field  specifies  which  LOAD  CLASS  statement  is  to 
be  referenced  to  determine  which  central  processor (s)  may  load  the  worker 
routine  named  in  the  first  field. 


NOTE 

There  must  be  a  PROGRAM  DISTRIBUTION  statement  for  each 
worker  routine  in  a  given  simulation. 


5.9  DUMP  CONTROJ-  STATEMENT 

5.9.1  Card  Code  29  ^ 

5.9.2  Dump  Table  1  Through  25 

The  first  twenty-five  fields (two  digits  each)  of  this  statement 
allow  the  user  to  specify  which  tables  are  to  be  dumped  at  pre-determined 


Intervals  and  at  a  simulation  termination.  The  following  value  in  any  of 
these  fields  controls  which  tables  are  to  be  dunq;>ed. 

0  =  dump 
-1  =  no  duiq> 


5.9.3  Trace 

Activating  the  trace  field  of  this  statement  will  cause  a  trace 
line  to  be  wltten  everytlme  an  Instruction  is  executed.  It  is  activated 
in  the  same  manner  as  the  dun^  table  fields. 


5.9.4  Snap 

The  snap  field  is  used  in  the  same  way  that  the  trace  field  is  used. 
In  addition  to  the  information  supplied  by  a  trace,  will  be  added  the 
identification  of  the  active  COT,  AT  and  lOT  (if  one  exists). 


NOTE 

The  interval  at  which  dumps  are  taken  is  controlled  by 
the  SIMULATION  CONTROL  statement,  which  is  described  below. 

If  a  diagnostic  occurs  during  the  pre-simulation  handling 
of  input  data,  the  dump  control  statement  is  disrogax’ded 
and  all  dump  tables  are  written  to  .tape. 


R.IO  STATISTICS  CONTROL  STATEMENT 


5,1C,1  Card  Code  30 


5,10,2  Statistics  Table  -1  through  10 

These  ten  fields  of  two  digits  each  will  specify  which  STATISTICS 
TABLES  are  to  be  developed  >'.t  the  time  intervals  specified  by  the 
SIMULATION  CONTROL  statement. 

The  following  value  in  any  one  of  those  fields  controls  which 
STATISTICS  TABLES  are  to  be  developed. 

0  =  develop  statistics 
-1  =  do  not  develop  statistics 
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5.11  SlMUIiATION  CONTROL  STATliAtENT 


5.11.1  Card  Code  31 

i 

5.11.2  Statistics  Interval 

This  fo\u'  digit  field  specifies  in  minutes  the  simulated  time 
interval  between  statistical  outputs  and/or  dumps. 


5.11.3  Total  Number  of  Intervals 

This  four  digit  field  specifies  the  total  number  minus  one,  of 
statistical  outputs  and/or  dump  to  be  taken  during  a  given  simulation. 
A  statistical  output  and/or  dump  is  automatically  taken  at  simulation 
termination. 


Narg 

If  the  values  in  the  two  fields  of  the  statement  when  multiplied 
together  are  greater  than  1440  minutes  (24  hours)  an  error  message  will 
be  generated  and  the  simulation  model  will  terminate. 


5.12  INTERRUPT  VECTOR  STATEMENTS 


There  will  be  an  Interrupt  vector,  associated  with  each  CPU  being 
represented  in  a  given  simulation.  This  Interrupt  vector  has  20  entries. 
The  first  8  entries  are  prs-assigned  and  will  be  used  for  the  following; 

1=1/0  termination 

2  =  Read/Write 

3  =  Function 

4  =  Clock 

5  =  Receive 

6  =  Program  termination 
,  7  =  End  of  seek 

8  =  Open/Close 


,  .The  first ^eight  entries  in  the  Interrupt  vector  of.  each .CPy.beln^^ 
represented  must  contain  a  transfer  address  to  the  appropriate  location’ 
within  the  operating  system.  The  remaining  12  entries  in  the  interrupt 
table  vector  are  available  to  be  used  as  the  configuration  of  the 
operating  system  dictates.  The  Interrupt  vector  table  is  represented 
by  two  interrupt  vector  statements,  each  of  which  contain  ton  fields. 


6-10 


naxmpi 


'•miAM  ^  rn 


6.13  INTERRUPT  VECTOR  STATEMENT  “1 

5.13.1  Card  Code  32 

5.13.2  CPU  Number 

This  four  digit  field  specified  the  CPU  to  be  associated  with  this 
interrupt  vector  table. 

5.13.3  0/S  Program  Number 

This  four  digit  field  specifies  the  operating  system  to  be  associated 
with  this  interrupt  vector  table. 


5.13.4  lntemq)t  Address  Number  1  through  Number  10 

The  ten  (four  digit)  fields  that  follow  must  contain  eight  Interrupt 
addresses  and  may  contain  two  optional  interrupt  addresses. 


6.14  INTERRUPT  VECTOR  STATEMENT-2 


5.14.1  Card  Code  33 

S 

The  format  of  this  statement  is  identical  to  Interrupt  vector 
statement  1  excepting  the  card  code.  If  an  operating  system  requires 
10  or  less  Interrupts  this  card  may  be  omitted. 


NOTE 

The  limit  on  the  number  of  interrupts  that  may  be  associated 
with  one  CPU  is  20.  The  first  eight  Interrupts  must  have 
.  addresses  and  the  twelve  remaining  interrupts  are  available 
to  the  user  at  his  option. 


.  A  .* 


»«.• 

5.15 


0/S  HE&DRY  ALLOCATION  STATEMENT 


•Jl  •  »  V..  *  -  •  . 


5.15.1  Card  Code  34 


5-11 


5.15.2  0/S  Program  Number  -  Memory  Number 

This  system  parameter  consists  of  five  paired  fields  of  four  digits 
each.  It  is  used  to  specify  in  which  memory,  a  particular  operating 
system  is  to  be  loaded.  There  must  be  one  paired  entry  for  each  operating 
system  being  simulated.  The  first  field  of  the  pair  will  designate  the 
operating  system  program  number  and  the  second  paired  field  will  specify 
the  memory  number  with  which  that  operating  system  is  to  be  associated. 

The  simulator  will  always  load  an  operating  system  into  the  low  order 
pages  of  memory. 


5.16  POISSON  FUNCTION  STATEMENTS 

The  following  two  system  parameters  will  all*,  the  user  to  replace 
the  Simulator's  Poisson  function  values  with  values  of  their  own  choice. 


5.16.1  Number  1  Poisson  Definition  Statement 


5.16.2  Card  Code  35 

The  rest  of  this  statement  consists  of  ten  (five  digit)  fields  to 
specify  a  value  for  the  argument  (o  through  45)  of  the  Poisson  function. 


5.16.3  Number  2  Poisson  Definition  Statement 

5.16.4  Card  Code  36 

The  ten  (five  digit)  fields  of  this  statement  will  specify  values 
for  the  second  half  of  the  Poisson  function  (50  through  95). 
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SECTION  VI 

OPERATING  SYSTEM  DESCRIPTIONS 


6.0  WORKER  ROUTINE 

All  W/R  statements  are  available  to  the  operating  system. 


6.1  CPU  ITEM 

There  is  a  three  word  CPU  ITEM  for  each  CPU  being  represented  in 
a  simulation  as  esqjlaincd  below. 


6.1.1  First  Word 

T1.3  first  word  contains  the  transaction  word  “TW  (address  of  the 
worker  routines  transaction  item  -  Tl)  of  the  current  operating 
transaction  -COT. 

6.1.2  Second  Word 

The  second  word  contains  the  transaction  word  of  an  available  trans¬ 
action  -  AT.  A  Current  Operating  transaction  automatically  becomes  an 
available  transaction  upon  crossing  the  boundary  into  the  operating 
system.  When  this  boundary  is  crossed,  a  new  transaction  item  is  pro¬ 
duced  to  represent  the  operating  system  and  becomes  the  current  operating 
transaction. 


6.1.3  Third  Word 

The  third  word  contains  an  lA*  transaction  word  -lOT  when  an  I/O  is 
to  bo  performed. 


6.1.4  Oporatlng/I>rinary  Statements 

The  atato»''nts  provided  for  the  use  of  the  operating  syatom  and  primary 
worker  routines  will  deal  with  available  or  1/0  transactions  (CYCLE  is  the 
'  exception).  •  .  i*. ,».••••  •  v  f>  j  •- »v  ...  .  .  .  . 

6.1.6  Transaction  Word  Uanipulotion 

Bow  transaction  words  ore  mnnipulatcd  within  a  CPU  ITEM. 


EXAMPLE:  Assume  a  t'orkor  Routine  goes  to  the  Otiorating  system  to  perform 
an  I/O. 


6-1 


1 


«R>001'  to  OS  for  READ 

06^X)T  tqton  crossing  08  boundary 

VR-AT 

OS<COT  an  I/O  transaction  item  is  produced 
WR>AT 

10n«I0T  when  OS  determines  and  I/O  is  required 

083<X}T  when  lOTI  has  been  sent  to  Future  Events 

WR>AT 

Chain  “  FBC  to  represent  I/O  tine 

WRbCOT  upon  returning  control  to  the  worker  routine  to 
eemtinue  processing  while  1/0  is  being  performed. 

OS  transaction  item  is  destroyed  wnen  leaving  the 
OS  boundary. 

6.2  CARO  FORUATS 

Card  formats  are  to  include  the  information  in  accordance  with  the 
sasfples  and  the  following  directions. 


6.3  CARD  CODE 

All  4  peratlng  system  and  worker  routine  statements  must  contain  an 
80  in  columns  1-2. 


6.4  WORKKl  ROUnNE  HUMBER 

All  statements  associated  with  a  particular  operating  system  or  worker 
routine  must  contain  that  routine's  number  in  columns  3-4. 


6.5  8BQUBCCB  KUUDSi 

All  operating  system  and  worker  routine  statements  must  contain  a  four 
digit  sequence  number  in  columns  3-8.  These  sequence  numbers  must  be 
incremented  by  unity  for  eech  statement. 

-XU. «V'i*  •  *■'''•1^00  str*emcntj  foj'oirins  tb^  roultnc's  . 

etatements  (card  type  81-85)  must  contain  the  sequence  number  0001. 

Operating  system  and  worker  routine  base  statements  (card  type  81-83) 
sequence  field  Mist  contain  scros  or  blan'xs.  These  statements  must  bo 
preaented  to  the  simtulalioo  model  in  the  order  in  which  they  are  herein 
described. 
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6.6  8YSTEU  ID 

Oolunns  76-80  aay  bo  used  for  a  systoM  ID,  TMs  field  will  not  bo 
examined  by  the  8imulaie  Hachlno. 

Columns  40-77  sre  not  examined  by  the  simulation  model  and  may  be 
U£Od  for  comments. 


MOTE 

A.  All  fields  (excepting  1-2  luid  3-4)  must  bo  four  digit  fields 
In  the  form  DIM>E/MNKN  as  specified  on  the  format  sheets. 

B.  DIHIE  will  bo  Interpreted  as  a  number  in  the  range  1-9999 
with  an  03q;>onent  in  the  range  0-9.  MNNN  will  be  inter¬ 
preted  as  a  number  in  the  range  1-9^70. 

C.  Unused  fields  may  bo  loft  blank  or  xero  filled. 

D.  All  used  fields  mttst  have  their  values  right  justified 
and  zero  filled. 

E.  When  assigning  absolute  addresses  to  TRANSFER  type  state¬ 
ments,  tlie  address  used  must  be  relative  to  the  first 
statement  following  the  worker  routine  base  statements 
(card  types  81  through  85). 


6.7"  31  UEMORY 
XSl 
N81>1 
MSI  ♦a 


KEN  1,  Ufai  a,  (ZERO,  QUEUE  NlTaER) 
NOT  BTOUGII  UEiORY 
PACK  NEEDH) 

KI3I0RY  AVA1LABI.E 


This  statement  examines  the  memory  nap  of  the  object  system  to  deter- 
nino  if  there  is  sufficient  storage  to  load  an  available  transaction  in  the 
range  of  memorloa  specified. 


6,7.1  rirat  Parameters 

The  first  paranetrr  specifics  the  first  no-ory  to  b^  rsanined. 


6.7.2  Second  Paraaetcr 

The  second  paremolcr  specif  1p<  the  I?’'-t  remry  to  be  examined. 
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6.7.3  Third  Parameter 


The  third  parameter  may  specify  either  zero  or  a  queue  number.  If 
it  is  zero,  the  test  of  memory  will  reference  the  AT  of  the  current  CPU 
item.  If  it  is  a  queue  number,  the  test  will  reference  the  entry  indi¬ 
cated  by  the  current  setting  of  the  pointer  for  the  quexie  specified.  If 
a  queue  is  specified,  it  must  be  one  whose  contents  are  designated  as  worker 
transactions.  Attempting  to  reference  a  queue  of  I/O  transactions  with 
this  statement  will  generate  an  error  message  and  terminate  the  simulation. 


6.7.4  Possible  Lxits 

There  are  three  possible  exits  from  this  statement  as  follows: 

a.  The  next  sequential  instruction,  (NSI)  will  be  executed  if 
there  is  not  enough  memory  to  run  this  worker  routine. 

b.  The  NSI+1  will  be  executed  if  the  total  storage  available 
will  satisfy  the  requirements  of  the  worker  routine  only  if  the  present 
contents  of  memory  are  compacted.  The  normal  operation  in  this  case  would 
be  to  PACK  storage. 

c.  The  NSI+2  statement  will  be  executed  if  there  is  enough 
storage  to  run  this  worker  routine  without  packing.  The  normal  coding  at 
NSI+2  would  be  an  ALLOCATE  statement. 


NOTE 

In  the  memory  range  specified,  memories  not  accessible  to  the 
current  operating  CPU  will  not  be  examined. 


6.8  32  ALLOCATE  MEM  .1,  MEM  2 

The  ALLOCATE  statement  examines  the  memories  specified  by  the  first 
operand  through  the  second  operand  and  assigns  the  quantity  of  memory 
required  by  the  AT.  If  the  AT  is  an  active  re-entrant  program,  only  the 
required  data  and  I/O  storage  will  be  allocated. 


NOTE 

A  MEIIOIIY  statement  should  always  precede  the  AI<LOCATE  state¬ 
ment.  Attempting  to  perform  an  ALLOCATE  statement  when 
sufficient  memory  is  not  available  will  generate  an 
appropriate  error  message  and  terminate  the  simulation. 
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6.9  33  DEALLOCATE 


The  DEALLOCATE  statement  examines  the  object  memory  map  and  releases 
all  storage  assigned  to  the  AT  subject  to  the  following  restriction.  If 
the  worker  routine  indicated  by  this  TI  Is  specified  as  re-entrant  and 
there  is  another  active  TI  associated  with  this  worker  routine,  only  data 
storage  and  1/0  storage  are  released.  For  a  re-entrant  worker  routine, 
instruction  storage  is  released  only  when  there  are  no  active  TI 's  in  -lie 
system  associated  with  this  routine. 


NOTE 

The  DEALLOCATE  statement  is  normally  followed  by  a 
DESTHOY  statement  to  eliminate  the  terminated  AT  from 
the  system.  Any  attempt  to  return  to  RETURN  with  an 
AT  which  has  no  memory  associated  with  it  will  generate 
an  appropriate  error  message  and  terminate  the  simulation. 


6.10  34  PACK  MEM  1,  MEM  2 

The  PACK  statement  causes  the  contents  of  storage  to  be  compacted 
starting  at  the  beginning  of  MEM  1  and  continuing  to  the  end  of  MEM  2. 

MEM  1  and  MEM  2  may  be  the  same  if  a  single  memory  is  to  be  packed. 

For  an  operating  system  providing  dynamic  compacting  of  memory  where 
necessary,  the  PACK  statement  is  nox’mally  coded  at  the  NSl+1  exit  of  the 
MEMQRY  statement,  followed  by  an  ALLOCATE  statement  at  KSl+R.  For  operating 
systems  which  automatically  pack  memory  when  any  is  released,  the  PACK 
statement  is  normally  coded  immediately  following  the  DEAIX.OCATE  statement. 


6.11  QUEUE  PROCESSING 

The  simulator  permits  the  operating  system  to  manipulate  queues  that 
are  defined  by  the  system  parameters.  Definition  of  each  queue  must  include 
the  following  information: 

A. ‘  Queue  number 

B.  Length  of  queue  (nunber  of  entries  permit  led) 

C.  Queueing  metl>od  <prc>;;ri>i.i  priority,  FIFO,  UFO) 

D.  Tj^jc  of  entry  permitted  (worker  routine  transaction  or  I/O 
transaction) . 
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Associated  with  each  queue  is  a  pointer  which  indicates  the  entry 
to  be  scrutinized  when  the  queue  is  being  scanned.  The  scanning  process 
is  accomplished  by  the  use  of  the  three  EXAMINE  statements,  v/hich  do  not 
«lter  the  contents  of  the  queue.  Transaction  words  are  entered  on  and 
removed  from  queues  only  by  the  PLACE  and  SELECT  statements,  respectively. 
No  item  may  appear  on  more  than  one  queue  at  any  given  time.  The  EXAMINE 
statements  and  the  SELECT  statement  will  ignore  any  queue  entry  which 
cannot  be  handled  by  the  current  CPU.  If  such  an  entry  ic  the  only  item 
in  a  queue,  the  NO  FIND  exit  will  be  taken. 


6.12  35  EXAIiQNE  -*  FIRST  QUEUE  NUMBER 

NSI  No  Find 

NSl+1  Find 

The  EXAMINE  -  FIRST  statement  makes  the  first  entry  (if  any)  in  the 
specified  queue  available  to  the  operating  system.  This  statement  causes 
the  pointer  to  be  reset  to  the  first  entry  before  the  queue  is  accessed. 
Contents  of  the  queue  are  not  altered. 

This  statement  has  two  exit  lines.  If  there  is  no  item  in  the  queue, 
the  next  sequential  instruction  (NSI)  will  be  executed.  If  there  is  an 
entry  in  the  first  queue  location,  NSI+1  will  be  executed. 

The  0/S  statement  which  is  coded  at  HSI-t-1  depends  on  the  nature  of 
the  queue  being  examined  and  the  reason  for  examining  it.  For  exai^pln, 
if  the  queue  contains  I/O  transactions  awaiting  initiation  which  are 
being  examined  to  determine  if  any  can  now  be  initiated,  NSI+l  would 
logically  contain  and  I/O  READY  statement. 


6.13  36  EXAMINE  -  NEXT  QUEUE  NUMBER 

NSI  No  Find 

KSl-M  Find 

The  EXAMINE  -  NEXT  etatenont  makes  the  next  entry  (if  any)  in  the 
specified  queue  available  to  the  operating  system.  This  statement  causes 
the  previous  setting  xif ■ the  queue  pointer  to  be ' tncromontod  by  1  before  the 
queue  is  accessed.  Contents  of  the  queue  sre  not  altered. 

This  statement  has  two  exit  linos.  NSI  will  bo  executed  if  the  entry 
being  examined  la  aero  or  the  end  of  the  queue  has  been  reached.  NSl4l 
will  be  executed  if  an  entry  is  present. 

The  0/S  statement  coded  at  N.*!!-*!  follows  the  same  principle  described 
in  connection  with  the  EXAMINE  *  FIRST  statcBont. 


NOTE 

This  statement  must  be  preceded  by  either  an  E>^IINE  “ 
FIRST  or  EXA\aNE  -  LAST  statement  referencing  the  same 
queue  to  insure  proper  processing. 


6.14  37  EXAinNE  -  LAST  QUEUE  NUMBER 
NSI  No  Find 

NSI+1  Find 

The  EXAMINE  -  LAST  statement  makes  the  last  entry  (if  any)  in  the  v 
specified  queue  available  to  the  operating  system.  Contents  of  the  queue 
arc  not  altered. 

This  statement  has  two  exit  lines.  If  there  is  no  item  in  the  queue « 
the  next  sequential  instruction  (NSl)  will  be  executed.  If  the  queue 
contains  one  or  more  entries,  NSI+1  will  be  executed. 


6.15  38  place  (at,  lOT),  QUEUE  NUMBER 

The  PLACE  statement  causes  the  transaction  word  (AT  or  lOT)  specified 
by  the  first  parameter  to  be  put  on  the  queue  specified  by  the  second 
parameter  according  to  the  qxteueing  method  (priority,  FIFO,  LIFO)  specified 
in  the  S/P  queue  definition  cai’d.  If  queueing  is  by  priority,  the  current 
item  will  be  placed  after  any  other  items  in  the  queue  with  the  same  priority 
level.  The  queue  pointer  is  set  to  queue  start  at  the  conclusion  of 
execution  of  this  statement. 


NOTE 

The  simulator  will  detect  as  un  error  any  attemt  to  place 
a  aero  item  on  a  queue. 

If  the  unued  queue  is  full  when  this  statement  is  executed 
an  error  message  will  be'  generated  and  th.'  simulation  will 
terminate. 


6.16  39  SU.IXrr  (AV,  lOT),  QUEUE 

The  SIXGCT  sl’.ilcmcnl  caiMes  the  iten  indicated  by  the  pointer  of  the 
queue  spoeiiicd  In  lh»-  sccomi  para:"  ter  t*»  N  rcf*avcd  fros  tl*c  queue  and 
placed  in  either  the  AT  or  lOT  of  tin  CPU  lt»t  r.«  sptclflrd  in  the  first 
p.nr.’irvoler.  Nhcn  the  SP.iVl  Ir.  lnl<  ipreled,  the  CPU  Item  specified 
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by  the  first  parameter  must  be  zero,  as  a  result  of  either  placing  the 
item  it  previously  contained  on  some  queue  or  destroying  it.  If  that 
word  is  not  zero,  an  (Appropriate  error  diagnostic  will  bo  generated  and 
the  simlation  aborted. 

Error  termination  will  also  result  from  an  attempt  to  select  from 
a  queue  either  a  zero-item  or  an  item  which  cannot  nm  in  the  current 
CPU.  Therefore,  in  a  multi -conputer  system  or  in  any  case  where  the  con¬ 
tents  of  the  queue  are  unknown,  an  EXAMINE  statement  must  precede  the 
SELECT  statement  to  Insure  that  the  queue  contains  at  least  one  item  which 
can  run  in  the  current  CPU. 

Following  execution  of  the  sa.BCT  statement,  the  queue  pointer  is  set 
to  queue  start. 


NOTE 


This  statement  will  reset  EXAMINE  pointer. 


Attenptlng  to  select  an  item  from  a  queue  of  the  wrong 
type  (such  as  selecti^-*  nn  AT  Irom  an  1/0  queue)  will 
generate  an  error  diagnostic  and  terminate  the  simulation. 

The  transaction  word  (in  the  CPU  item)  specified  by  the 
first  parameter  must  be  zero.  If  it  is  not,  an  error 
message  will  be  generated  and  the  simulation  will  be 
terminated. 


6.17  40  BUFF 

MSI  Eecord  Available,  No  I/O  Necessary 

NSl-fl  Kocord  Available,  Initiate  1/0 

NSl^S  Mo  Record  Available 

The  BUFF  statement  permits  the  operating  system  to  determino  the 
necessity  for  performing  an  1/0  operation  based  on  current  state  of  buffers. 
«•  .•t  j  a**;  tfh  s..wt.rkrr.,r'‘vtf  T,TMi 

transferred  to  the  operating  system  at  the  REAUAltl TE  interrupt  location 
which  normally  causes  a  BUFF  statement  to  bo  executed.  The  BUFF  statcbenl 
interrogates  present  buffer  contents  for  the  file  to  be  read  or  vritten  to 
see  if  a.  a  record  is  available  end/or  an  IA>  operation  is  necessary. 

The  BUFF  statement  has  three  exit  lines  as  follox^s: 
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1.  NSl  Is  executed  if  there  is  a  record  available  and  there  is  no 
buffer  empty  for  a  READ  or  full  for  a  WRITE.  NSI  is  nornally  coded  as  a 
RETURN  to  the  worker  program  which  issued  tho  READ  or  WRITE  command. 

2.  NSI-fl  is  executed  if  a  record  is  available  but  one  buffer  is 
enpty/full,  indicating  that  an  I/O  operation  should  be  initiated.  At  this 
point  an  1/0  transaction  item  is  created.  Normally  tho  NSl-t-l  exit  should 
transfer  control  to  a  test  for  10  READY,  which  will  either  initiate  the 
I/O  operation  or  queue  it,  followed  by  a  RETURN  to  the  originating  worker 
or  selection  of  a  new  AT. 

3.  NSI+R  is  executed  if  there  are  no  records  available.  This  exit 
can  be  reached  only  if  all  possible  1/0  operations  have  previously  boen 
initiated  but  not  yet  completed.  The  normal  coding  at  this  point  nay  be 
to  place  the  workor  routine  on  a  deferred  queue  and  to  select  a  new  AT. 

NOTE 

In  those  eases  where  a  record  is  available,  the  record  count 
for  tho  file  is  updated  before  the  NSI  or  NSl+l  exit  is  taken. 


6.18  41  SEEK 

XSl  Seek  Initiated 

NSl-fl  No  Sock  Required 

The  SEEK  statomont  allov;s  an  operating  system  to  perform  a  positioning 
operation  on  a  i.uidoB  access  device  without  keeping  the  cliannel  and  control 
unit  busy.  The  seek  statcBcnt  first  examines  the  device  type.  If  the 
device  is  not  a  random  access  device,  the  NO  SEEK  REQUIRED  exit  is  taken. 

The  next  test  cxanlncs  the  T0*-FR0M  Tabic.  If  tho  TO-FROU  table  entry  is 
aero  or  negative,  the  NO  SEEK  REQIDRED  exit  is  taken. 

If  the  SEEK-1 KITIATEO  exit  is  taken,  tho  JOT  is  placed  on  tho  Future 
Events  Chain  O'BC)  and  the  JOT  in  tho  current  CPU  item  is  set  to  aero. 

When  this  item  cornea  off  the  FEC,  it  will  generate  a  SEEK  Interrupt. 

If -the  SEEK  atatcrent  ia  not  used,  tho  seek  time  apocifled  in  the 
TO-FROU  Tabic  will  Ik>  added  to  the  Rend-Vrite  tine  oiid  will  bold  the  channel 
ami  control  unit  b4u;y  foe  the  entire  operation. 


6.18  43  JO  REUiY  (EldO.  QUEUE  KU>3tER) 
MSI  BVSV 

RSI  41  RRrVW 
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Ihe  10  READY  ■tatement  la  ua'ed  to  determine  whether  the  facilities 
(filei  device,  and  channel-control  unit  path)  required  for  an  10  operation 
are  available.  If  the  paraneter  is  zero,  the  teat  ia  made  for  the  current 
lOT.  If  the  parameter  ia  a  queue  number,  the  teat  ia  Mde  for  the  item 
indicated  by  the  current  setting  of  the  pointer  for  that  queue. 

This  statement  has  two  exit  lines.  NSl  will  be  executed  if  any  of 
the  necessary  facilities  is  busy,  NSI-i-1  will  be  executed  if  all  are 
available.  If  the  test  was  made  for  an  item  on  a  queue,  the  READY 
exit  should  lead  to  a  SELECT  statement  to  remove  that  item  from  the  queue 
and  make  it  the  lOT. 


HOTE 

If  the  paranete**  indicates  a  queue,  it  must  be  one  whose 
contents  are  specified  as  I/O  transactions.  Attempting 
to  perform  this  operation  on  a  queue  of  worker  trans¬ 
actions  will  generate  an  error  message  and  terminate  the 
simulation. 


6.  SO  43  10  ADVANCE 

Th«  10  ADVANCE  statement  is  used  to  indicate  the  initiation  of  an 
1/0  operation  for  a  worker  routine.  An  10  ADVANCE  statement  must  follow 
the  READY  path  of  an  10  READY  statement.  The  Interpretation  of  an  10 
ADVANCE  statement  places  the  lOT  on  the  future  events  chain  (FEC)  for  the 
time  required  to  perform  the  I/O  operation,  and  clears  the  lOT  to  zero. 

In  completion  of  the  operation  the  next  sequential  instruction  (NSI)  is 
executed. 


NOR 


A.  If  any  file,  device,  control  unit,  or  channel  required 
for  this  I/O  operation  is  busy,  and  not  assigned  to  this 
particular  worker  routine,  the  appropriate  diagnostic 
message  will  be  supplied  and  the  simulation  terminated. 

B.  Attempting  to  perform  an  10  ADVANCE  instruction  with  a 

-  V'  vimert  'ZOT  t'.ll  i:iJr,.'ra Ve-vn  .e-j-or  s-r:a!*.rc  r‘v\  ••'r;? 

the  simulation. 

C.  Ho  interrupts  may  be  allowed  between  an  10  READY  and  an 
10  ADVANCE. 
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6.21  44  10  TERM  QUEUE  NUISER 

NSI  May  not  proceed 

NSl+1  May  proceed 

Tho  10  TERM  statement  tostfl  the  item  indicated  by  the  current  setting 
of  the  pointer,  for  tho  queue  specified,  to  determine  if  the  item  is  a 
transaction  item  which  can  now  proceed  due  to  the  termination  of  the  current 
1/0  transaction  item  (lOT).  A  tr.uisaction  item  is  able  to  proceed  if  it  is 
associated  with  the  ciurront  1/0  transaction  item.  A  transaction  item  is 
not  able  to  proceed  if  it  is  not  associated  with  the  current  1/0  transaction. 

This  statement  has  two  exits.  The  next  sequential  instruction  (NSl)  is 
executed  if  the  worker  transaction  indicated  by  the  pointer  may  not  proceed. 
The  NSl-i-l  is  executed  if  the  worker  transaction  may  proceed. 


NOTE 

The  queue  specified  by  the  operand  of  the  statement 
must  contain  a  worker  transaction  item  or  else  an 
a4>propriate  diagnostic  message  will  be  supplied  and  the 
simulation  terminated. 


6.21.1  Operating  System  Switches 

There  are  three  operating  system  statements  which  handle  the  sotting 
and.. testing  of  200  switches  provided  for  use  by  the  c^orating  systems  and 
the  primary  worker  routines.  The  three  statements  are  SET,  RESET,  and 
TEST. 


Switches  numbered  101-200  are  global  and  nay  be  used  as  liaison 
between  operating  systems.  Each  of  the  5  CPU's  permitted  in  a  simulation 
may  have  xqi  to  20  local  switches  (1-20). 


6.22  46  SET  SWlTai  MUMPER 


The  SET  atotemont  turns  on  one  of  tho  200  operating  ayatem  global 
awitches.  The  switch  to  be  turned  on  is  indicated  by  the  switch  paramoter. 
If  the  switch  to  be  SET  is  alread:  on,  it  will  be  left  on. 


SOTt 


At  the  stnrt  of  a  simulRtion  all  switches  ere  off. 
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6.23  46  RESET 


SWITCH  MUllBER 


The  RESET  statement  turns  otf  one  of  the  200  operating  system  global 
switches.  The  switch  to  be  turned  off  is  specified  by  the  switch  parameter. 
The  RESET  statement  has  no  effect  if  the  specified  switch  is  already  off. 

HOTS 

At  the  start  of  a  simulation,  all  switches  are  off. 


6.24  47  test  SWITCH  NUMBER 

NSl  SWITCH  ON 

N8Z+1  SWITCH  OFF 

The  TEST  statement  tests  one  of  the  200  operating  system  global  switches. 
The  switch  to  be  tested  is  indicated  by  the  switch  number  parameter.  There 
are  two  exits  from  thl^  statement.  The  next  sequential  instruction  will  bo 
executed  if  the  switch  tested  is  on.  Tlie  NSI-t-1  will  be  executed  if  the 
switch  Is  off. 


NOTE 

At  the  start  of  a  simulation,  all  switches  arc  off. 


6.25  48  INTERRUPT  CPU,  INTERRIPT  NUIBER 

The  INTERRUPT  statement  allows  an  operating  system  to  generate  an 
interrupt  which  will  effectively  be  placed  at  the  top  of  the  Future  Events 
Chain  (FBC).  The  first  operand  specifies  the  CPU  wiilch  is  to  be  interrupted, 
and  the  scond  operant  specifics  the  number  of  the  internq>t.  The  current 
operating  program  will  not  lose  control  of  the  CPU,  unless  the  CPU  being 
interrupted  is  the  CPU  executing  the  current  operating  program. 


/»*  V* 


NOTE 

The  following  conditions  are  recognired  as  errors  in 
,,tbe  use  this  statcncut  aud^  111  cause  an  error  mossarc 
tho 'terminnUou' or  ihe 'sim\il’«ii6nl  •  ■  ’ 

a.  The  Specification  of  an  interrupt  number  not  defined 
in  the  operating  system  specified. 

b.  The  specification  of  a  CPU  which  drnrs  not  use  the 
oporatlnc  system  dcfin''d. 
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The  first  eight  locations  in  tho  interrupt  vector 

•re  reserved  for  prc~assigncd  entries  into  the  operating 

system  and  may  not  be  accessed  by  the  INTBRRUPT  statement. 


6.26  49  DISABLE  (ALL,  INTERRUPT  NUMBm) 

llie  DISABLE  statement  forces  the  sirulator  to  defer  tho  occurrence 
of  any  or  all  of  the  interrupts  specified  at  the  start  of  the  operating 
system.  If  tho  parameter  specified  is  ALL,  all  interrupts  will  be  deferred. 
A  single  interrupt  may  bo  deferred  by  inserting  its  ordinal  interrtftt 
number  into  the  INTEIUlllPT  number  parameter. 

If  a  transaction,  upon  reaching  the  top  of  the  Futiu'O  Events  Chain 
(FEC),  finds  that  its  interrupt  action  has  boon  disabled,  it  will  remain 
on  the  FEC  until  and  enable  statement  allows  it  to  enter  the  internet 
routine. 


NOTE 

The  number  0099  indicates  that  ALL  interrupts  arc  to  be  disabled. 


6.27  50  KNABIiE  (ALL,  INTMlhUPT  NDMOFR) 

The  OUUR.E  statement  causes  the  simulator  to  stc^  deferring  tho 
interrupts  specified  by  the  operand.  This  statement  is  used  to  reverse  the 
•ctlonr.  specified  in  a  DIRABJ.E  statcmcht.  If  an  interrupt  which  was 
deferred  by  n  D15tAnLE  statciucnt  becootes  active  by  an  ENABl.E  atatoment,  it 
will  cause  an  interrupt  as  soon  as  a  CPU  advance  lime  occurs. 


NOTE 

The  number  0009  indicates  that  all  interrupts  arc  to  be 
enabled. 


6.28  51  CLOCK  LHiiiK  (TIRE  IN  VE) 

!.*.•  Clio,  ^  .-  t  «.  s t ...u! te<l  •  l  •*  I.  .  ..  »’  I  'lV'..  . 

a  clock  interrupt  whm  it  rearhes  aero,  unlrr*.  ihv  interrupt  is 

disabled.  Vhen  the  C1.0CK  staler:  nt  la  interpreted,  tlx-  value  of  the  operand 
la  placed  into  the  aimulated  Inlerv.'^l  destroylee  any  previous  aeltln,.. 

Once  the  interval  liner  ha«  reached  rero,  ih'^rvb)  pcnerMlnj:  an  inlerrm»t, 
another  interrupt  msy  not  occur  until  the  lie  -  h;»»  bv-’u  rv  J'.-t  b>  a  new 
a4>CK  St  ntcocnl. 


6-13 


6.29  TIMK 


This  field  specifies  in  Microseconds,  the  interval  between  interrupts. 
The  vslue  of  this  field  Must  be  in  the  fore  n>DB. 

MOTE 

In  a  Multiple  GPU  environstont  there  is  one  CLOCK  per  CPU. 


6.30  53  RETURN 

The  RETURN  statenent  is  used  to  leave  the  operating  systen  and  return 
to  the  next  statenent  of  the  routine  represented  by  the  AT.  The  AT  will 
Boraally  represent  a  worker  routine  but  it  nay  be  a  prinary  worker  or 
another  entrance  in  the  operating  systen.  When  the  RETURN  statenent  is 
interpreted,  the  COT  (representing  the  operating  systen)  is  destroyed 
and  the  AT  (representing  the  worker  routine)  boconcs  the  COT. 


MOTE 

A  RETURN  nay  not  be  executed  if  there  is  not  AT  or  if  there 
is  an  lOT  in  the  current  CPU  iten.  Either  of  these  cases 
results  in  an  appropriate  error  nessage  and  ternination 
of  the  simulation. 


6.31  53  ACTIVAIB  PROGRAM  NUUBER 

The  ACTIVATE  statenent  causes  the  Ismcdiate  generation  of  a  transaction 
iten  for  the  progran  specified  by  the  paranoter.  la  addition,  the  trans* 
acti<»)  workd  for  this  transaction  beeosics  the  AT  in  the  curi-ent  CPU  ITEU. 
Before  the  operating  systen  executes  an  ACTIVATE  stateuent,  the  AT  in  the 
eurrent  CPU  ITEU  lUSt  bo  set  to  aero  by  a  DFSTROY  or  a  ri.ACE  statenent. 


ISZI 

If  it  is  possible  for  an  ACTIVATE  statenent  to  be  executed 
by  a  CPU  which  is  incapable  of  cxcruting  the  transaction 

queue  before  it  lx  naripulalv*!.  ]n  Ihix  ca'sc,  th.-  StJ.hO' 
statenent  will  ignore  this  transaction  wvrd  since  the  current 
CPU  can  not  process  it. 
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6.32  O']  RECKIVE 

The  RECEIVE  statcuent  taken  the  transaction  item  associated  with  a 
program  Just  entering  the  system  and  places  it  in  the  AT  of  the  current 
CPU  item.  Before  executing  this  iitstruction,  the  operating  system  must 
insure  that  the  AT  word  of  the  current  CPU  item  is  aero  by  placing  the 
AT  on  a  queue  or  by  destroying  it. 


6.33  53  CYCLE 

The  CYCf.E  statement  allows  an  operating  system  to  enter  a  wait  state 
whore  the  CPU  is  not  actively  processing  any  operating  systen  or  worker 
routine  statements.  Normally  the  CYCLE  will  be  used  only  alien  there  is 
no  available  transaction  in  the  entire  systoM.  Before  executing  a  CYCLE 
statement,  the  operating  system  must  ensure  that  all  interrupts  are 
enabled,  the  AT  is  xcro,  and  lOT  is  zero.  If  any  of  these  conditions  is 
not  fulfilled,  an  error  message  will  be  generoted  and  the  simulation 
terminated. 


6.34  56  DESTROY  (AT,  IOT> 

The  DESTROY  statement  causes  the  specified  wvrd  (AT  or  lOT)  of  the 
current  CI>U  item  to  be  cleared  to  zero  snd  the  asaociatod  transaction  item 
to  be  removed  from  the  system. 

A  DESTROY  statement  specifying  the  AT  is  normally  used  only  ss  a 
result  of  worker  program  termination.  A  DI.’STUOY  stateaent  specifying  the 
lOT  normally  follows  the  tcr«inntlon  of  sn  I/O  operation. 


NOTE 

If  the  wT>ikt'r  routine  associated  with  the  AT  being  destroyed 
has  any  files  that  have  not  been  closed,  an  error  messtge 
will  be  generated  and  the  sieiulaticni  will  tcroinatc. 


6.35  57  PERiPItRttAL  0,  or  QUEUE  KUVttEK 

KSl  Rt3?iriKm  >TU:?/D>:VICi:S  NOT  AtAU.Ma.l;  • 

NilU  AL»-  Ut  ».r  ii.  VlCf  >  KL  '-RVi.i 


The  PrairHEEAl.  »t»tcecnt  alloir-  the  files  r.nd  di-vJce*.  ?'r.r>cistrd  with 
a  worker  routine  to  Nr  exa^inod  amt,  jf  rvriletdc,  to  iho  t^r~cr 

routine . 
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There  arc  two  possible  exits  from  this  statement.  The  next 
Instruction  (NSI)  will  be  executed  if  the  required  files/devices 
available.  NSI+1  will  be  executed  if  all  required  f 1 les/devices 
available. 


sequenti al 
are  not 
are 


6.35.1  0,  or  Queue 

If  the  first  parnmeter  of  this  statement  is  0,  tho  files  associated 
with  the  AT  in  the  CPU  item  will  bo  examined  for  availability.  If  a  queue 
number  is  inserted  in  the  one  parameter  associated  with  this  statement, 
tho  files  associated  with  the  transaction  item  indicated  by  the  queue 
pointer  will  be  examined  for  availability. 


NOTE 

Tho  use  of  the  PERIPIIETIAL  statement  does  not  obviate 
tho  need  for  an  OPEN  statcniont  in  the  worker  routine. 

The  PElllPlIERAL  statement  simiily  reverses  f i Ics/dovicos . 
The  OPEN  statement  actually  assigns  them  to  the  worker 
routine  if : 

A.  A  queue  is  referenced,  it  must  bo  the  type  that 
contains  AT  transaction  woi*ds,  or  a  dlcignostlc 

will  bo  generated  and  tho  simulation  v,ill  terminate, 

B.  A  queue  is  referenced,  and  the  queue  pointer 
indicates  a  zero  word  within  the  queue,  a  diagnostic 
will  be  generated  and  tho  simulation  will  terminate. 


6.36  INTERRUPTS 

Upon  tho  occurrence  of  an  enabled  interrupt  the  operating  system  will 
receive  control  of  the  CPU  v/hich  was  interrupted,  at  the  location  specified 
in  tho  interrupt  vector  table  for  this  intcj'riipt.  The  following  section 
describes  the  current  CPU  status  when  the  operating  system  receives  control. 


6.37  I/O  I'EHMINATION 

« 

Ap  .  I/p  ^  i  f .  ,  v/hen.  an  ,1/0  operation 

initiated  by  an  10  AnVANX’K  s {atcmcnt  has  reached  the  top  of  tho  future 
events  clialn,  (EEC)  indicating  complct i on.  V.'lion  this  occurs,  the  current 
operating  transaction  (COT)  is  made  the  available  transaction  (AT),  (a) 
and  the  1/0  transaction  fro;:  the  top  of  the  future  events  chain  bocon.es 
the  current  I/O  traji.-;acti<»ii  (JOT).  If  there  is  a  possibility  tliat  the 
transaction  item,  whic}»  initiated  the  I/O  oporatio.i  just  termi  nati  lig,  was 
placed  on  n  dcfcTrcd  queue  because  it  could  not  continue,  it  may  be  found 
by  means  of  the  10  TERM  statet  enL, 


G-IC 


(S)  An  opornllng  system  transaction  item  is  gcnci*atcd  as 

the  cor. 


6.38  #2  RKAD-WRIl’E 

A  REf\D-WRlTE  interrupt  occurs  when  n  current  operating  transaction 
executes  a  read  or  a  write  statement.  V.'hcn  this  occurs,  the  current 
operating  transaction  (COT)  is  made  the  available  transaction  (AT)  and  an 
operating  system  transaction  is  generated  as  the  COl*.  The  operating  system 
address  for  a  Rli\D-V/RITE  interrupt  is  normally  a  BUFF  statement. 


KOTR 

If  the  operating  system  Issues  a  UJltU  or  a  WRITE  statement, 
the  READ-WRITE  interrupt  must  be  EJiARLED  and  the  AT  and 
the  lOT  must  be  zero.  Whenever,  the  operating  system  is 
interrupted,  any  current  AT  will  be  destroyed,  and  an  lOT 
may  be  destroyed. 


6.39  #3  FUNCTION 

A  FUNCTION  interrupt  occurs  when  a  current  operating  transaction 
executes  a  FUNCTION  statement.  V/hen  this  occurs,  the  current  operating 
transaction  (COT)  is  made  the  availnble  transaction  (AT),  and  an  operating 
system  transaction  is  generated  as  the  (COT),  and  an  I/O  transaction  is 
generated  and  made  the  current  lO'T.  The  normal  oi;orntlng  system  address 
for  a  FUNCTION  interrupt  is  an  10  READY  statement. 


NOTE 

When  an  operating  system  executes  a  FUNCTION  statement, 
the  function  interrupt  must  be  enabled. 


6.40  P'1  CIDCK 

A  CI-OCK  Interri'pt  occurs,  II  o:'.:. bled.  When  the  Internal  timer  for  a 
CPU  roaches  zero.  The  interval  time  is  set  by  the  CLOCK  statement,  and 
may  be  used  for  any  purpose.  When  the  CI.OCK  interrupt  occurs,  the  current 
operating  transaction  (COT)  becomes  the  available  transaction  (AT)  and  an 
operating  system  transaction  is  generated  as  tlic  COT. 
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6.41  #5  RECEIVE 


A  RECEIVE  interrupt  occurs,  if  enabled .  when  a  program  reaches  the  top 
of  the  future  events  chain  for  the  first  time.  At  this  time  the  program  Is 
being  entered  Into  the  system  to  con^eto  for  system  facilities.  When  this 
occurs,  the  current  operating  transection  (COT)  is  made  the  available  trans¬ 
action  (AT)  and  an  operating  system  transaction  is  generated  and  made  the 
COT.  Before  the  transaction  word  identifying  tne  program  received  can  be 
made  available  to  the  operating  system,  the  available  transaction  must  bo 
queued  or  dostioycd.  The  now  program  transaction  word  is  made  the  AT  by 
the  RECEIVE  statement. 


6.42  #6  PROGRAM  'n:KMlN.iTION 

A  PROGRAM  TfStuUKATlON  interrupt  occurs  when  any  routine  executes  a 
TERM  statement.  When  this  occurs,  the  current  operating  transaction  (COT) 
which  is  the  terminating  program  is  made  the  available  transaction,  and  an 
operating  system  transaction  is  generated  as  the  COT.  It  is  then  the 
operating  system's  function  to  deallocate  memory  and  to  destroy  the  termina¬ 
ting  program's  transaction  word. 


6.43  m  END  OF  SEEK 

An  END  OF  SEEK  interrupt  occurs,  if  enabled,  when  a  seek  operation 
initiated  by  a  SEEK  statement  is  complete.  When  this  occurs,  the  current 
operating  transaction  (COT)  is  made  the  available  transaction  (AT)  and  the 
seek  1/0  transaction  word  is  made  the  lOT.  At  this  time  it  is  the  operating 
system  function  to  do  a  now  10  READY  operation  to  atten^t  to  begin  the 
actual  1/0  operation  requested  initially. 


6.41  #8  OPEN-CLOSE 

An  OPEN-CLOSE  interrupt  occurs  when  an  OPEN  or  CLOSE  statement  is 
executed.  When  this  occurs,  the  current  operating  transaction  (COT)  is 
made  the  available  transaction  (AY)  and  on  operating  system  transaction 
is  gencroted  as  the  COT.  In  addition  an  1/0  transpction  is  generated  as 
the  lOT.  At  this  point  it  is  the  operating  system  function  to  perforin  an 
JO  READY  opcrutlor.. 

6.45  90  END  INPUT 

The  END  INPW  signifies  to  the  simulator  that  all  input  data  for  a 
given  slmulatii>n  hns  been  received.  It  must  be  the  last  c.ard  of  the  input 
data. 
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SECTION  VII 


■ORKER  ROUTINE  STATEUENTS 
DESCRIPTIONS  MfD  FORMATS 


7.0  CARD  FORMATS 


7.1.1  Card  Code 

All  operating  sjstca  and  worker  routine  statCMCuts  oust 
oobtain  an  SO  in  COlubna  1-2. 


7.1.2  Worker  Routine  Kuabor 

All  atatooonts  aaaocinted  with  a  particular  operating  syatca 
or  worker  routine  auat  .contain  that  routine’s  nuaber  in  Coluans  3-4. 


7.1.3  Sequence  Niiinf>cr 

All  operatinf.  systen  and  worker  routine  atateaenta  auat  contain 
a  four  digit  aequonce  number  in  Coluana  5-8.  Tlter-c  sequence  numbers  uu.st 
be  incremented  by  unity  for  each  statcuc:^. 

The  first  worker  routine  stateaent  following  the  routine's  base 
atatcaents  (card  type  81-85)  aust  contain  the  sequence  nuaber  OOOl. 

Operating  systea  aitd  worker  rcnitln?  base  statements  (cart!  type  81-85) 
sequence  field  aust  contain  sero^  or  blanks.  These  statenents  must  be 
presented  to  the  sitisulation  model  in  the  order  in  which  they  arc  herein 
described. 


7.1.4  System  lU 

CO)ti«in.>i  76-80  be  o.scd  for  a  systen  ID.  This  field  will  not  be 
exaulnt-d  by  the  Simulate  Muchtne. 

*rt  *7  If..*  ...  «|»  .*  Hx-  th--  .  -  *  ♦r’t'  '■►.I'J  >».>*|  .--y 

U.'t'ti  lor  'tt«r  . 


1  1 


KOTE 


A.  All  fioldx  (cxocpting  1>2  and  3-d)Bmsl  bo  four  digit  fields 
in  the  form  D!H)K/NNNN  ns  specified  on  the  format  sheets. 

B.  IHM)E  will  be  interpreted  os  a  minbcr  in  the  range  1-999 
with  an  exponent  in  the  range  0-0.  NXNN  will  be  interpreted  as  a 
number  in  the  range  1-9999. 

C.  Unused  fields  may  be  left  blnn!:  or  zero  filled. 

D.  All  used  fields  must  have  their  values  right  Justified  and 
soro  filled. 

E.  Vhen  assigning  absolute  addresses  to  TRAKSEEIt  type  statements, 
the  address  used  must  be  relative  to  the  first  ttotenent  following  the 
worker  routine  base  statements  (card  ty|X!S  SI  through  85). 


7.2  jon 


7.2.1  Card  TyjK; 

Uusl  be  81.  Only  one  JOU  statement  may  be  asrocinteii  »ilh  a  t'ovker 
Ro'.  tine. 


7.2.9  Program  Type 

This  field  must  specify  oiw  of  the  follov  tiig: 

1  =  Operating  System 

2  r.  Primary  korkev  Routine  for  r.v;ii^j>lc,  the  leader  routine  may 

be  co.ir- idert «l  a  sty  . rate  pro..r.an  to  be  called  by  the  Oi'crating 
Systew  a.'.  ntjuirvU. 

3  V  Cowf^eitial  tyjK-  Toiler  Routine 
d  Scicntlfir  tyi’-'  tio-kc  r  K*»ut  iiK* 


7.2.3  InfoiTiii it -1 

This  fk-ld  rv.::l  sjvelfy  if  a  Rmitine  rryresentr.  n  non 

re-rnirnnt  or  re-entiaul  t>T-  pren’"’- 


t  a 


I  "  Non  rc-onl  raiil 


2  =  Uc-cntranl 


7.3  ORDINAL  Flf.R 


7.3.1  Card  'fypc 

Musi  bo  82.  Thui’c  may  bo  as  many  tyjio  82  cards  as  required  to 
describe  tlic  file's  ar.socialcd  with  a  Worker  Routine. 


7.3.2  Ordinal  File  Number 

Tills  field  specifics  the  Ordinal  File  number  that  a  Worker 
Routine's  stalerienis  reference.  For  cxaniplc,  a  READ  3  will  icferencc 
the  third  Ordinal  I'ilc  statement. 


7.3.3  Rc'al  File  Nuiiibcr 

Tlii.s  field  specifies  tl;o  Real  File  to  be  associated  with  the  Ordinal 
File  rerereiiecd  in  t'  e  V.'orkei'  Rouline'.s  stalewents.  If  for  example, 

W/R  3  ifiei'i.  . ..  .  -e.  til.  luav’.ei  I'cue  (r./F  1)  as  0/1'  3  and  V.’/R  4 
references  the  saf.e  lotidci'  qtuiie  (R  F  1)  as  0/F  5,  then  the  connection 
bctv.’ecn  the  Ordinal  and  R^ml  files  allows  the  Sirrulatc  Machine  to 
dctcJiiiine  for  any  V.'oi'ker  Routine,  when  it  issues  an  I/O,  the  proper 
paths,  availability  and  I/O  time. 


7.3.4  Number  Buffers 

This  field  sjK'cifie;;  tlK-  number  of  buffers  a.ssociated  witli  tlio 
Real  File  as  used  by  this  V.'orkci-  lioutiiic. 


7.3.5  Assign 

Tlii.s  fic;ld  Slic'd  f.  es  in  rorn:al  ion  relative  to  tlie  a.;;.ig;nini;  of 
files  ;i 'd  d.-\iees  to  a  Woi'kci-  Routine. 

1  '  No  a;'. si  [•.I  !  icnt 

2  ■  Asr’o.n  file  to  Worker  Rouline 

''  A  '.si  .n  file  and  de\  ii;e  to  V.iirki  a  Roul  in  ' 
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A  check  will  be  made  against  Configuration  Data  to 
determine  if  device  assignment  is  permitted. 


7 . 4  MEMORY  1 


7.4.1  Card  Type 

Must  bo  83.  Only  one  Memory  1  statement  may  be  associated  with 
a  worker  routine. 


7.4.2  Number  Instructions 

This  field  specifics  the  number  of  instructions  in  the  worker 
routine.  The  value  of  this  field  must  be  expressed  in  the  form 
DDDE . 


7.4.3  Number  Characters 

Tlvis  field  specifies  the  nui..ber  of  alpha  characters  (data)  in 
the  worker  routine.  The  \'aluo  of  this  field  must  be  expressed  ’  ” 
the  foi'm  DUDE. 


NOTE 

The  valves  inserted  in  the  MEMORY  1  statement  must 
not  include  INPUT- Oli'iPUT  buffer  memory  requi  rc^m.ents  . 


7 . 5  MEMORY  2 


7.5.1  Card  Type- 

Must  ho  S-’.  Only  one  MEMORY  2  statement  may  be  associated  with  a 
worker  routine. 


7.5.2  Number  Nuii'eric  Con;;  1  au i 

Tlii.s  field  sped  fie;;  the  num'.ier  of  deeima]  fields  ii,  tlic  woi'ker 
rout  ine.  The  v.alu,-  of  litis  li< Md  i.iust  I'l-  c  xp.i'c:;sef!  in  t)ie  form  DUUE. 


7- 


7.5.3  Average  Length  (Numeric  Constant) 

This  field  specifies  the  average  field  leiibth  of  the  numeric 
constant  mentioned  in  the  previous  field. 


7.5.4  Number  Binary  Fields 

This  field  specifies  the  mimbor  of  fixed  point  (binary)  fields 
in  the  worker  routine.  The  value  of  this  field  must  be  expressed  in 
the  form  DDDE. 


7.5.5  Average  Length  (Binary) 

This  field  specifies  the  average  number  of  decimal  digits  for 
the  decimal  fields  mentioned  in  the  previous  parameter. 


7.5.6  Number  Floating' Fields 

This  field  specifics  the  average  number  of  decimal  digits  per 
floating  field.  The  value  of  this  field  must  be  expressed  in  the 
form  DDDE. 


7.5.7  Average  Length  (Floating  Fields) 

This  field  specifics  the  avei'agc  length,  in  decimal  digits,  of 
the  previous  field. 


NOTE 

If  the  information  contained  in  this  statement  i.s  not 
pertinent  to  the  simulation  ol  a  Worker  Routine,  the 
entire  statement  may  be  omitted. 

If  any  fields  in  a  MEMORY  2  siatement  do  not  apply  to  a 
particular  Worker  Routine,  those  field.s  may  be  left  blank. 
The  memory  required  for  INPUT-OUTPUT  buffers  must  not  be 
included  in  this  state.nent. 
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7 . 6  GENEUATK 


7.6.1  Card  Type 

Must  bo  85.  Only  ono  GENEUATJ.  statement  may  be  as.sociatcd  with 
a  worker  routine. 


7.6.2  Spread 

This  field  specifies  (in  seconds)  a  creation  interval  expressed 
either  as  a  fixed  number  or  as  a  Poisson  function.  The  value  of  this 
field  must  be  expressed  in  the  form  DDDE. 


7.6.3  Fixed  Poisson 

This  field  specifics  a  1  to  indicate  that  the  previous  field 
represents  a  fixed  number  or  a  2  to  indicate  a  Poisson  function. 


7.6.4  Creation  Limit 

This  field  specifics  the  crerttion  limit  for  a  worker  routine. 
If  this  field  is  left  blank,  the  worker  routine  will  be  generated, 
according  to  the  SJTd'/'Jl  value,  until  the  simulation  is  terminated. 


7.6.5  Priority 

This  field  specifies  the  p;-iority  to  be  associated  with  a  worker 
routine.  The  value  of  this  field  may  fall  within  the  range  0-99.  If 
this  field  is  zero  or  blank  the  woriccr  routine  will  be  assigned  a 
standard  pi'iority  as  defined  in  the  system  parameter  Card  typo  27. 

The  h:i'd!e.st  priority  will  bo  1  and  is  reserved  for  the;  Operating  System 
Pioutinc. 


NOTE 


Any  fields  that  are  not  required  may  be  left  blank. 

i  .  ^  I  ,  i  ' .  I  ,  I  .  ■  ^  '  S  t  C  .  .  r  . .  I  J  i  .(*  *  .t', .  v-'.l  a  ;  .  V-  .  j  ».  t  _  V.  i 

routiiie  and  operating  sy.ston  I’ouliue  evci.  tliough  all 
of  the  fieJd.s  aie  blank. 
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7.V  TRANSFER 


/.7.1  Card  Typo 
Must  bo  01. 

7.7.2  Location 

Hiis  field  specifics  the  location,  within  the  same  Worker 
Routine,  to  which  an  unconditional  transfer  is  to  be  made. 

7.8  TRANSFER  PROBABILITY 


7.8.1  Card  Type 
Must  be  02. 


7.8.2  Percentage 

The  value  in  this  field  will  indicate  the  probability  of  transfer 
to  the  location  named  in  the  1/)CAT10N  field.  If  the  probability  tran.sfer 
is  not  executed,  the  next  sequential  statement  will  be  executed. 

s 

7.8.3  Location 

Tills  field  contains  the  location  (within  the  .same  Worker  Routine) 
to  which  transfer  on  probability  is  to  be  made. 


EXAMPLE:  TRANSFER,  40,  JACK 

This  statement  indicates  a  60rc  chance  of  selecting  the  next 
instruction  and  a  40%  chance  of  a  transfer  to  JACK. 


7.9  READ 

.■  ’  ...  \  . 

7.9.1  Card  Typo 


7-- 7 


Must  be  03. 


7.9.2  File  Number 


This  field  contains  the  Ordinal  File  number  to  be  read.  The 
Real  Pile  number  associated  v/ith  this  V,’orker  Routine's  Ordinal  File 
will  direct  the  Simulate  Machine  to  the  information  required  to 
perform  this  input. 

NOTE 

When  this  statement  is  used  in  an  oporatiiiK  system, 
the  READ-V.'RITE  interrupt  must  bo  enabled. 


7.10  WHITE 


7.10.1  Card  Type 
Fust  be  04. 


7.10.2  File  Number 

This  field  contains  the  Ordinal  File  number  to  bo  written  to. 

NOTC 

When  this  statement  is  used  in  an  operatine  system, 
the  READ-WmiE  interrupt  must  be  enabled. 


7.11  05  FUNCTION  FUNCTION  NUMRER 

The  FUNCTION  statement  causes  an  immediate  function  interrupt  in 
the  oporatint:  system,  and  the  i;eneratlon  of  an  I/O  transaction  item. 
The  duration  of  the  I/O  operation  initiated  by  the  operating  system  ns 
the  result  of  the  function  interrupt  is  governed  by  the  entries  in  the 
system  function  table.  Tlio  function  number  operand  of  this  statement 
specifies  the  entj’y  in  the  system  function  table  which  is  to  be 
referenced  by  the  10  ADVANCE.  Each  entry  in  the  system  function  table 
specifics  the  length  of  time  the  channel,  control  unit,  and  device 
are  to  be  busy  with  this  I/O  operation. 


The  FUNCTION  statement  is  not  considered  a  normal  I/O 
operation  and  .should  be  used  only  for  I/O  operations 
which  car.  not  be  represented  in  any  other  way. 

This  operation  may  be  used  by  worl:ei'  roullnc. 
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I 

1! 


7.12 


EOF 


7.12.1 


Card  Typo 


Must  bo  06. 


7.12.2  File  Number 

This  field  specifies  which  ordinal  file  is  to  be  checked  for  an 
EOF  condition. 


7.12.3  Location 

Ibis  field  contains  the  location  to  which  a  transfer  is  made 
upon  detection  of  an  EOF  condition. 

NOIE 

This  statement  allows  the  Vorkev  Routine  to  check  for 
an  EOF  relative  to  the  information  given  for  that  file 
in  the  System  I’arameters.  Tlio  Simulate  Machine  keeps 
•*  a  tally  of  blocks  road/written  as  I/O's  arc  executed. 

When  an  EOF  statement  is  encountered  a  comparison  will 
bo  made  between  Block  Count  Tally  and  the  file  size 
(System  parameters).  If  the  Block  Count  Tally  is  greater/ 
equal  the  file  size,  a  transfer  will  be  made  to  the  addre.ss 
In  the  location  field  of  the  statement.  Otherwise  the  next 
sequential  statement  will  be  executed. 

The  EOF  statement  may  not  be  used  to  check  for  a  file's 
end  if  that  file  has  been  opened  more  than  once. 


7.1.3  SUBK 


7.13.1  Card  Type 
Mu.sf  be  07. 


i: 

[ 

[ 


7.13.2  Location 


This  field  specifics  the  starting  addrci^s  (within  the  Worker 
Routine)  of  a  subroutine. 


MOTE 

A  Worker  Routine  is  permitted  three  nested  SUBR 
calls  at  any  given  tine.  If  this  ri^lc  is  violated, 
the  appropriate  diagnostic  will  be  given  and  the 
simulation  will  terminate. 


7.14  EXIT 


7.14.1  Crrd  Type 
Must  be  08. 


KO'n; 


This  statement  will  cause  the  statement  immediately 
following  llio  last  SUI5U  Call  t<»  bo  executed  next. 


7.15  LOOP 


7.15a  Card  Typo 
Must  be  09. 


7.15.2  Value 

This  field  specifics  the  number  of  times  the  transfer  to  the 
location  named  in  the  next  field  will  occur. 


7.15.3  location 

Tills  field  specifies  the  loc  tion  (within  the  V.'orkoi-  Routine) 

ul  ihc  ucx:  li.  i.'  . .  k  .1  *..>/!  S  .  .1  i  vi  ..'ll  i  is' 

executed,  a  IXlOP  Counit  i-  \.ill  be-  dr  ere  ..in  let!  aii'I  a  trnioifer  to  the 
address  in  the  location  field  t  ill  tn.l.e  plnec.  V.hon  tlic  Loop  Counter 
is  decremented  to  zero,  th>>  n*  xl  .‘erpieul  ial  slnU'.;d>l  will  be  executed 


NOTE 


The  Worker  Routine  is  pemittod  three  nested  LO(N*S 
at  any  given  tine.  If  another  LOOP  statement  is 
encountered  while  all  three  Loop  Counts  contain  a 
value,  it  must  bo  assumed  that  the  logic  of  the  Worker 
Routine  is  correct.  Therefore,  all  Loop  Counts  will 
be  set  to  soro  and  the  LOOP  statoment  Just  encountered  will 
DOW  become  the  first  LOOP  of  the  set. 


7.16  MOVE 

7.16.1  Card  Type 
Must  be  10. 


7.16.2  Number  Giaracters 

This  field  specifies  the  number  of  characters  to  be  moved  as  a 
■enory  to  memory  transfer  of  data.  A  simulated  time  advance  will  be 
calculated  by  applying  the  logical  unit  sir.e  of  the  computei  being 
simulated  to  the  value  of  this  field. 


7.17  MOVE-E 

7.17.1  Card  Type 
Must  bo  11. 


7.17.2  Number  Oiarnctcrs 

Thin  field  specifies  the  number  of  characters  to  be  moved  >kitliin 
a  memory  on  a  character  by  char.’.ctcr  basis.  The  logic.al  unit  ot  rtcrory 
of  the  Computer  being  simulated  will  determine  the  simulntcd  time 
advance  required  to  represent  the  action  of  this  statement. 


< .  J ..  vO. .  i  . 


7.18.1  Card  Type 
Must  Ih?  12. 


7-11 


7.18.2  Number  Instructions 


This  field  Ki>ocifics  a  value  representing  a  mix  of  instructions 
to  be  executed.  The  Simulate  Machine  will,  using  the  value  of  this 
field,  produce  a  probability  variable  rhlch  will  be  used  to  calcul;ite 
a  simulated  time  advance. 


7.18.3  Hark  Number 

This  field,  if  non-blunk,  s|jccifics  the  nui4lH.-r  of  the  Ordinal  ll^irk 
Accumulator  to  be  incremented  by  the  value  associated  with  the  previous 
field.  Tlic  maximum  nuial>cr  of  Oidinal  M:.r!:  Accumulators  that  may  bo 
referenced  is  10.  The  use  of  this  Parameter  will  permit  statistics  to 
bo  gathered  for  specific  sections  of  an  Operating  System  or  Primary 
Worker. 


MOTE 

The  use  of  the  MAUK  Numt>or  field  is  reserved  for  Operating 
S>.i  tern*,  and  frinary  Workers. 

If  an  Ordinal  liturl:  Acc.uu.alalor  numbci  greater  than  10  is 
encountered,  n  diagnostic  and  sicailntion  abort  will 
occur. 


7.19  MA'ni 

7.19.1  C«|-d  Type? 

Must  be  13. 


7.19.2  NumiK.  r  Acid s 

Tl»ts  field  spc.i"  j  fi  es  llu-  r  uf  add  i  I  (or  Kubl  rr.c  t  it>ns)  l»> 

be  sit  alnied. 


7.19.3  Kamber  UtiHlj.lys: 


7.19.'t  NuM^N-r  Uividf  .*- 

Tb »  n  r  U  ? d  jij  <  i  f  i  I-'.  !  J  •  !•-  »  of  d  •  \  t i*  I *•  I  ■  1  ’  c  -i . 
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HaiK 

The  Simulate  Uachinc  will  assuinc  that  tlio  values  of 
fihcsc  fields  represent  separate  and  complete  calcula¬ 
tions.  For  example;  in  a  word/roi;inter  computer, 
one  add  tine  would  include  a  memory  to  register 
transfer,  add  tine  and  a  recister  to  memory  transfer. 


7.20  OPFK 


7.20.1  Card  Tjpe* 
Must  he  11. 


7.20.2  File  Kumber 

Tills  field  siHH-ifics  the  Oixlinnl  file  miulier  to  be  oiicned. 

7.20.3  3xi*UT“0irn*irr 

This  flcli}  specifies: 

1  »  INFUT  file 

2  -  OtnT'Ut  file 

7.21 


7.21.1  C.ird  TyiK 

itu.s  (  be  1  r> . 


7.21.2  File  XV.bcr 

Th  1  f  ic  J  «t  S  i  f  i  «■  *  t  !■■;■  O!  tt  '  1*4*  I  flit-  *i»;  •  t  ■  ■  I  In  t  --  C  t  c*r  't  . 

7.21.3 

T>i»?^  *  i  f  *«■<  it  t'-e  fit*  Ki  .  rip  «»'  i.  t«'  I  r.  4 '• 

or  i*«t  ,  ***-  foil**- 


1  c  ncv'iiid 

2  =  No  Kcwind 


7.22  TER.MIN.\TE 

7.22.1  Card  Typr> 
Nust  be  16. 


7.22.2  Call  W/H 

Tills  field  Is  u.scd  if  tho  imnodiatc-  getifratiun  of  a  woikcr 
routine  is  dcpciKtciit  upon  the  ternination  of  another  worker  routine. 


BI.\NK/y!:iiO  V  No  worl'.cr  routine  to  called. 

K0.\-U1.V\'K  •-  Ti’c  nuiiher  of  the  woikcr  routine  to 

be  called. 


NOiK 


The  ITKMINATE  sU«tcm>uil  must  i>e  the  last  statCM-nt  in 
a  worker  routine.  If  a  IKRMIXATi;  statCBicut lt.(;ical 
pc  it  ion  in  a  worker  routine  is  othci  th.'in  the  Inst 
atatciuent,  it  r.ust  still  be  placed  at  the  end  of  the 
routine  nml  a  TKAXSl.vn  made  it  frora  the  t«oint  where 
it  would  nonually  have  been  placed. 


7.23  TkRVU.VATt:  SiATI'»4rLNT.S 

it  is  jHiEiitlvti  to  hn»e-  two  T13V'.jX.*.‘iK  h  I.t  Icrien  t  s ,  but  they  Wiust 
be  sd^iav-<  nt  and  b*.-  the  last  two  statecieuls  i.i  the  routine.  I'or  exawplc, 
if  a  Welker  routiiu;  wants  to  tcrr.inate  and  call  aiuttlKt  worker  routine 
on  r  prubabMit)  of  IOC.,  the  vill  ppp.'ar  a.-*  follot^c 

T»;a  ;k>  •  to  .  h'-i.  -  . 

TKtCtINA-,r 

jad;  irt.viwiv  rM.i.  t/r.  v. 


fit 


llic  iiil rocluc t ion  into  tho  .systor.i  oT  ;i  woi'l.or  rcuilinc-  i-.s  n 
result  of  tlu'  CALI  W/ll  pn’-iimoior  will  have  no  oTfecl  on  tlic  value  of 
the  CRKA'I  L  LIMIT  in  tl'.e  GJLNKli/A'i'L  si  a  I  chuMit . 

The  'ILltMlNATK  .slaleii.enl  r.nist  aj)poaj-  even  tliou^h  it  is  never  used. 
An  opei’cilin'i  .sy.>; (cm,  for  example,  iiio.st  be  active  until  a  siraulalion  is 
halted  by  r.  time  lii.iil  or  Irek  of  ac;ti-vi1y,  but  it  must  also  have  a 
TEId.lJNATL  statcmeni  a.s  it's  last  instruction. 


7.24  NO-OP 


7.24.1  Card  Type 
Must  be  99. 

The  NO-OP  stalc-tntMit  allo'.vs  dcOelions  to  l)c  made  to  a  Worker 
Routir.e  lliat  lias  already  been  written  in  absolulc  foi-mat  without  the 
need  to  altci'  absolute  addi’c.sr.e.s  as.socialcd  aitii  Trv-\.\f''rjht  tyijo 
statement  s . 


NOTK  ■ 

The  fol  apj'.lics  to  Operatinti  System  statements. 

There  are  two  vaiys  to  dele  te  a  statcricnt  tliat  has  an 
an  NSl  and  an  KSlil  line  a‘'  riated  wi  tli  it. 
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WORKING  PAPER 


APPEN’DiX  A 
GLOSSAUV 


INTRODUCTION 


The  explanations  of  the  various  terms  contained  in  this  glossary  are 
directly  relative  to  the  siinuJation  model 


AT— Available  Transaction 

An  available  transaction  is  a  transaction  that  is  available  to  be 
manipulated  by  an  operating  system  or  a  primary  worker.  It  is  represented, 
in  the  second  v/ord  of  a  CPU  item,  by  a  transaction  word  (TV/). 


Buffer 

A  buffer  is  a  unit  of  data  v/hose  dimension  is  expressed  in  characters 
and  number  of  records.  File  length  is  expressed  in  buffers.  The  DUFF 
statement  (0/S)  will  examine  the  buffer  count  associated  with  the  named 
file  when  an  operating  system  or  worker  routine  attempts  an  I/O.  It  must 
be  determined  if  an  available  record  exists.  (S/P  card  tjpo  26). 


C/D — Configuration  Data 


The  configuration  data  is  the  means  by  which  the  hardware  characteristics 
of  a  given  computer  may  bo  entered  as  input  data  to  the  simulation  model. 


COT — Current  Operating  Transaction 


The  COT  is  that  transaction  (TV!)  word  that  occupys  the  first  word  in  a 
CPU  item  and  is  considered  to  be  the  current  operating  transaction,  either 
in  a  worker  routine,  primary  worker  oi*  the  operating  system. 


CPU  Item 

There  is  a  CPU  item  for  each  CPU  being  represented  in  a  simulation. 

A  CPU  item  may  Ikj  considered  to  consist  of  three  words.  The  first  word  is 
used  to  contain  a  transaction  work  (TIY)  representing  a  current  operating 
transaction  (COT),  the  second  w’ord  is  used  to  contain  a  transaction  word 
(T»'0  representing  an  available  transaction  (AT)  and  the  third  word  is  used 

OpcraliiVij  fc»ystci<i  rnd  \(u‘l;cr  I'Oiriinc  s Iciijvnt  descriptions  spccjly  tiic 
requirements  and  limitations  of  tjaniaction  words  (TV/)  within  a  CPU  item 
relative  to  a  given  stnlcinonl. 
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Tho  cycle  statement  allows  an  operating  system  to  enter  a  "wait"  state 
whore  tho  CPU  is  not  actively  processing  any  operating  system  or  worker 
routine  statement.  (0/S  card  type  5!>). 


Povico  Penalty  Time 

Certain  devices  arc  capable  of  providing  faster  1/0  times  if  the  time 
between  I/O  operations  docs  not  exceed  a  certain  limit.  Device  penalty 
time  is  tliat  time  which  is  to  be  added  to  tho  normal  I/O  time  if  no  1/0 
call  to  a  device  has  occurred  before  the  specified  time  limit.  (C/D  card 
typo  05). 


Device  Selling  Code 

The  device  seizing  code  Indicates  to  the  simulation  model  whether  or 
not  a  named  device  may*  bo  specifically  assigned  to  one  worker  routine  for 
any  period  of  simulated  time.  (C/D  card  type  10). 


Dovico  Transfer  tfidih 

Tho  transfer  width  is  the  number  of  bits  which  arc  transferred  as  a 
unit  to  or  from  a  device  excluding  parity  or  other  check  bits.  (C/D  card 
typo  03). 


End  of  Sock 

End  of  ccel:  indicates  to  the  simulation 'model  that  an  I/O  to  a  random 
access  device  has  boon  broken  into  two  parts.  The  seek  and  the  I/O  trans¬ 
mission.  An  end  of  seek  condition  causes  an  interrupt  at  the  seventh  word 
of  the  interrupt  vector.  (0/S  card  t)’i)c  41). 


EOF — End  of  File 

EOF  is  a  worker  routine  statement.  (V’/R  card  type  OG) . 


FEC — FutufO  Events  ChniM 

The  future  events  chain  is  used  by  the  simulation  model  executive  to 
maintain  a  list  of  all  transaction  items  or  I/O  transaction  items  that  are 
using  simulated  time.  The  FEC  list  will  contain  a  transaction  word  (Tt.) 
representing  a  transaction  item  or  an  I/O  transaction  1  Ick  and  vd  n  co,r.-r  i- 
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iiiXorinutlon  lliat  will  allow  the  Kiinulatiou  model  executive  to  determine  tbo 
reason  lor  tJiat  transaction  word  being  on  the  list.  The  FJ3C  is  that  device 
which  allows  lor  the  possibility  ol  continuous  interrupts  and  is  osscntlally 
responsible  lor  incrementing  tJic  simulated  clock  as  transaction  words  (Tff) 
are  removed  from  tlio  luturc  events  chain  and  re-enter  the  simulated  system. 

FIFO 

FIFO  means  First  In  -  First  Out  and  is  used  in  conjunction  with  the 
ordering  oX  queues. 


Fi  lo 

A  111c  represents  IhTbT/oiTi'PUT  data  on  any  device.  Its  length  is 
determined  by  a  file  description  statement  (S/F  card  type  26)  which  dclines 
the  number  ol  records  per  bullcr,  number  ol  characters  per  bullcr  and  the 
number  per  lllo. 


Function 

A  lunction  is  used  to  represent  1/0  operations  which  cannot  bo  represented 
by  a  noriiial  road  or  v/ritc.  (S/P  cjird  type  05). 


Interrupt  Vector 

The  interrupt  vector  is  the  liaison  between  the  simulation  executive 
and  an  operating  system.  There  must  be  an  interrupt  vcctoi*  associated  with 
each  C1>U  being  represented  in  a  simulation.  The  llrst  eight  addresses  in 
the  twcfiity  location  interrupt  vector’  arc  pro-assigned  and  must  contain  trans- 
Icrs  to  various  parts  ol  an  operating  system. 


lOT— IkTUl/OUTPlTf  li  ansactlon 

An  INPUT/OUlPlJr  transaction  is  generated  every  time  a  worker  routine  or 
operating  system  statement  rcquirliic  an  1/0  is  interpreted  by  tlic  simulation 
executive.  Tlie  10  transaction  item  will  be  maintained  within  the  system 
until  the  10  has  been  eos.plolod  and  accounted  lor.  An  30  transaction  word 
v.'i  1 1  >’c  '-n  r<<  1  he  se-'v  I'ric-  ^  .'•5'  ini.-  voi-n  ifj  i  t  m.-. 

**».  .-*^  t:  j  .*  w.  th  j'ii  *4  i-jn-  Jo  1 4  .iiisae  ti  o;i  itc-i-i  n.-*  jixed  in 

the  location  assigned  to  it  when  it  was  generated.  * 


1  Oil.— I  KPliT/OU  1  in I'j'  Ti •.aiisnction  \?ord 
.See  JOT. 
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LIFO  means  Last  In  “  First  Out  and  is  used  In  the  ordering  of  queues. 


Load  Class  Kntry 

The  load  class  entry  statement  Is  used  to  dcsienato  which  of  the 
central  proccssor(8)  being  represented  are  able  to  load  a  given  workei* 
routine.  This  statement  is  used  in  conjunction  with  the  run  class  state- 
ment  and  the  program  distribution  statement.  (S/p  card  type  24,  S/P  card 
t)rpo  25,  S/l’  card  type  2C). 


Logical  Data  Unit 

The  logical  data  unit  is  the  primary  unit  of  data  processed  by  a 
given  CPU.  (C/D  card  typo  01). 

Memory  Access  Time 

Memory  access  time  is  the  minimum  time,  expressed  in  microseconds, 
between  the  start  of  a  memory  access  and  the  availability  of  tlic  data 
accessed.  (C/D  card  type  03). 


Memory  Access  Unit 

A  memory  access  unit  is  t)io  number,  of  usable  bits,  not  including  parity 
or  other  check  hits,  which  arc  accessed  by  a  single  memory  reference. 

(C/I)  card  typo  03). 


Memory  Allocation  Scheme 

The  memory  ulloealJlon  suliC'iuf  nJlov.s  the  usor  to  doscrJl)^  tho  mnnnor  In 
which  the  sltiuilalipii  model  is  to  nllucnte  moiiiory,  (i9/p  card  type  27), 


Mci(>ory  Cycle  TJtiiC 

Vemovy  ryelo  time  Is  the  ininlinnm  tlii'o,  expressed  in  mi Oiroseeonds , 
access  to  the  same  memory  unit.  (C/D  card  type  03), 


Mul U plexor  Channel 

A  multiplexor  cliaiviel  is  cupuhlt:  of  {ran'  -1  •  i  .  ?  . 

OirypUi'  at  a  tiro.  It  ir  capabJc  <<('  a  . 
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transDilttinc  a  single  message  (burst  ntocle)  then  when  transmitting  multiple 
messages* 

0/S — Operating  System 

At  least  one  program  designated  as  an  operating  system  must  be  asso“ 
dated  v/lth  each  simulation.  An  operating  system  may  have  associated  v/lth 
It  various  primary  worker  routines  which  It  will  call  upon  to  perform 
various  operations. 


Ordinal  Flic 

Ordinal  flics  arc  the  moans  by  which  worker  routines  can  reference  files 
In  any  named  manner  that  is  desired.  Ordinal  files  are  associated  with 
real  files  by  ordinal  file  statements  (V.'/K  card  type  82). 

Pago 

A  page  is  a  subdivision  of  a  memory.  It  indicates  to  the  simulation 
model,  the  smallest  unit  of  memory  that  can  be  used  in  allocation. 


Poisson  Function 

A  poi.sson  function  is  tJic  means  by  which  specific  values  can  bo  varied. 
Its  purpose  in  this  simulation  model  is  to  allow  the  user  tlic  facility  of 
obtaining  a  variable  value,  while  preserving  the  mean  of  the  distribution, 
in  contrast  to  being  required  to  use  the  moan  value  each  time  lor  those 
instructions  that  advance  the  simulated  clock.  (.S/2’  card  tjTjc  35  and 
card  type  3G). 


Primary  IVorkoj- 

A  prl mai*y  v/orkor  is  a  subpi'Ogi’am  of  an  opcj’ating  system.  Its  priority 
must  be  lower  than  that  of  the  opcj'aling  systor.i  with  wJiich  it  is  associated 
and  it  must  be  called  by  the  operating  sy.stcm  to  perform  its  function. 


PfOgraTH  T)j  <:1  l«.t  '  op  ^  .  j-  u 

The  progr.ain  distribution  stalcmont  indic.-ites  %  hi  eh  central  procossor(s) 
may  receive  a  wox'kcr  routine  and  which  central  jjrocessor (s)  may  run  Hint 
worker  routine.  The  pi'ograiii  di s tri buti on  staler-cnl  is  used  in  conjuriction 
with  the  load  class  st.Tteineiit  .'ind  lIs?  run  clr.'?r.  slr.lcucnil  (S/P  card  type 
28,  card  typo  24  and  card  tjjic  25). 
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Real  File 


Worker  routines  are  written  naming  ordinal  files.  These  ordinal  files 
are  associated  with  real  files  (W/R  card  type  82),  The  real  files  are  used 
when  simulating  the  performance  of  1/Os  for  worker  routines  and  operating 
systems.  The  real  file  is  Identified  and  described  by  an  S/P  card  typo  21. 


Receive 

The  fifth  word  in  the  interrupt  vector  is  considered  the  receive 
Interrupt,  and  is  the  means  by  which  an  operating  system  is  informed  that 
a  new  worker  routine  has  been  generated  and  is  ready  to  be  entered  into  the 
simulated  system. 


Record 


A  record  is  that  unit  of  data  which  is  considered  to  be  transferred 
when  a  worker  routine  or  an  operating  system  is'ues  an  1/0.,  It  is  also 
used  to  determine  a  buffer's  size.  (S/P  card  type  26). 


Run  Class  Entry 

Run  class  entry  statement(s)  indicates  to  the  simulation  model  which 
central  processor (s)  can  ran  a  program  that  has  been  loaded  into  a  given 
memory.  (S/P  cai*d  type  25). 


s 

Selector  Channel 


A  selector  channel  differs  from  a  multiplexor  channel  in  that  it  can 
handle  only  one  INPUT/OUTPUT  message  at  a  time. 


S/M — Simulation  Model 


S/H  is  an  abbreviation  used  for  the  simulation  model  in  the  User's 
Manual . 


SMI 

SMI  refers  to  the  pre-sj mulation  portion  of  the  simulation  model.  It 
is  that  portion  of  the  simulation  i.odel  that  accepts  the  input  data,  and 
chocks  it  for  accuracy  and  consistency.  SMI  is  responsible  for  constructing 
tables  from  the  input  data  that  will  bo  acceptable  by  S:i2. 
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SM2 


SM2  refers  to  that  portion  of  the  simulation  model  which  is  responsible 
for  actually  running  the  simulation  after  SMI  has  accepted  the  input  data. 

It  is  also  referenced  as  the  simulation  executive. 


System  Definition 

A  system  definition  statement  presents  to  the  simulation  model  such 
information  as  standard  priority,  memory  allocation  scheme  and  the  asso¬ 
ciation  between  operating  system  progiam(s)  and  CPU(s).  (S/P  card  type 
27). 


S/P — System  Parameters 


The  system  parameters  are  the  liaison  between  the  worker  routines, 
operating  system(s)  and  the  configuration  data.  Refer  to  the  S/P  portion 
of  the  User's  Manual  for  a  complete  description  of  the  input  data  associated 
with  this  module  of  the  simulation  model. 


To-Prom  Table 


The  To-Prom  Table  is  constructed  by  SMI  and  is  used  during  the  running 
of  a  simulation  to  determine  the  seek  time  required  when  initiating  an  1/0. 
It  is  essential  y  a  table  containing  seek  limes  between  the  various  files 
that  may  be  located  on  the  same  device. 


TI — Transaction  Item 

A  transaction  item  represents  an  active  v.orkcr  routine,  primary  worker 
or  operating  system.  It  is  a  table  that  contains  information  pertinent  to 
the  I’unning  of  the  program  which  it  represents,  A  tr.ansaction  item  is 
generated  whenever  a  new  program  enters  the  simulation  model  and  will 
remain  in  the  system  until  that  program  is  terminated.  (See  TW) 


HV — Transaction  Word 

A  transaction  word  is  associf'rKl  v.ithevci'y  ti'ansaction  item  in  the 
5.  li  .'.l,  L.oi  !..  1  i.<  a  p.,i‘ii.;ular‘  '  '  ^ 

transactioi.  item  and  is  moved  aboai  fne  systcii  as  the  siimala.tioa  progresses. 
It  may,  for  cxa.i.iplc,  be  connadered  the  COT,  tlie  AT,  on  the  lOT,  in  a  CPU 
item.  It  is  put  on  the  fiituro  evoris  cliain  when  simulated  time  is  being 
represented  rcl.ativc  to  a  particular  trrnsaetjon  ito!.>. 
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DT  Chain  Dump  Formats 


WORKING  PAPER 


System  Parameters  and  Configuration  Data  Input 


The  following  errors  are  detected  by  the  presimulation  (SMI)  as  it 
accepts  the  configuration  data  ard  system  parameters  input.  These  errors 
are  serious  causing  a  print  out  to  the  console  printer  and  immediate 
termination  of  the  simulation  model. 


First  card  not  type  1 

The  first  card  in  the  input  data  is  not  a  type  1  CPU  statement.  It 
is  either  missing  or  out  of  sequence. 


Type  2  Card  Error 

A  type  2  CPU  statement  is  missing,  or  out  of  sequence. 


Type  2  Card  Sequence  Error 

The  CPU  ID  for  this  statement  does  not  match  the  CPU  ID  for  a  type  1 
statement. 


Card  Type  3  Missing 

There  is  no  type  3  statement  in  the  configuration  data  input  or  the 
statement  is  not  in  its  proper  sequence. 


Number  of  Channel  Entries  Exceeds  50 

The  limit  of  SO  channels  has  been  exceeded.  A  multiplexor  channel  is 
considered  2  units  regarding  the  limit  of  50. 


Number  of  Devices  Defined  Exceeds  50 


The  restriction  of  a  maximum  50  different  types  of  devices  has  been 
exceeded . 


Card  Type  5  Sequence  Error 

There  is  no  type  5  device  statement  or  it  is  not  in  its  proper  sequence. 
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CPU  Kunibor  Greater  than  i) 


Only  5  central  processors  may  be  represented  in  a  given  simulation. 

Card  Type  6  Sequence  Error 

The  CPU  identification  statement  is  missing  or  out  of  its  proper 
sequence. 

More  than  10  Memories  with  1  CPU 

A  simulation  model  limit  has  been  exceeded. 

Sequence  Error-Card  Tyne  7 

Memory  Statement  information  has  not  been  received  sequentially. 

Card  Type  7  and  Type  3  Do  Kot  Match 

The  memory  information  in  the  type  7  statement (s)  is  less  than  complete, 
or  contradictory  to  the  memory  information  supplied  in  the  type  3  statement. 

Card  Typo  7  Missing 

There  is  no  type  7  memory  statement  in  the  configuration  data  input, 
or  i\  is  out  of  sequence. 

Channel  Definition  Missing 

There  must  be  a  tj^ic  8  channel  definition  statement  associated  with 
each  type  4  channel  statement. 

More  than  20  Channels  to  a  CPU 

A  simulation  model  limit  has  been  exceeded. 

Card  Type  8  Er ror  -  CPU  Nv-nibcr  Greater  Than  Five 
A  simulation  model  limit  has  been  exceeded. 
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Availability  Tnblu  Overflow 


More  than  200  availability  tabic  entries  have  brx'r.  received.  Each 
control  unit/channel  path  to  a  device  is  considered  one. entry. 


Function  Number  Greater  than  100 


A  simulation  model  limit  has  been  exceeded.  This  is  a  result  of  too 
■any  functions  being  named  by  the  type  22  system  parameters  input. 


More  Than  2000  Queue  Entries 

A  simulation  model  limit  has  been  exceeded.  This  information  was 
received  from  type  23  queue  statements  in  the  system  parameters. 


Card  Type-23  Sequence  Error 

The  queue  numbers  in  the  type  23  card  have  not  been  received 
sequentially. 


Queue  Method  Code  E^ror 

An  unacceptable  number  has  been  found  in  the  queue  method  field 
(S/P  Card  Type  23).  The  acceptable  entries  are  as  follows: 

1  «  rilX) 

s 

2  =  UFO 

3  *s  Priority 


Queue  Tyne  Code  Error 

An  incorrect  queue  typo  code  has  been  found  in  the  queue  control  field 
(S/P  Card  typo  23).  The  acceptable  codes  are  as  follows: 

1  =  AT 

2  =  JOT 


Number  of  Queues  Defined  Greater  thnn  30 

A  simulation  model  limit  has  been  cxcoodod  by  tho  B/P  typo  23  queue 
statement. 
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Card  Tyye  24  Sequence  Error 


The  load  class  statement  information  concerning  load  class  entry 
numbers  has  not  been  received  sequentially. 

More  Than  15  Load  Class  Entries 

A  simulation  model  limit  has  been  exceeded  by  the  B/P  type  24  load 
class  statement. 

Load  Class  CPU  number  greater  than  5 

A  simulf'^'cn  model  limit  has  been  exceeded  Ly  the  8/P  type  24  load 
class  statement (s) . 

Card  Type  25  Sequence  Error 

The  run  class  entry  statements  have  not  been  received  sequentially. 

More  than  5  Run  Class  taitrics 

A  simulation  model  limit  has  been  exceeded. 


Run  Class  CPU  Number  Greater  than  5 

k  simulation  model  limit  has  been  exceeded  by  a  type  25  system 
parameter  statement. 


Card  Typo  26  Sequence  Error 

The  6/P  file  description  statements  are  not  sequential  relative  to 
the.  real  file  numbers. 


Card  Type  26  Duplicate  File  Kumbor 

A  real  file  has  boon  referenced  more  than  once  by  sn  8/P  file  des¬ 
cription  statement. 


File  Placed  on  Device  ?’ui«bcr  Crenter  than  100 


The  device  number  field  of  the  S/I*  typo  26  file  description  statement 
bos  exceeded  a  simulation  rckIoI  limit. 


a>,Typg  gy,  Cord 


The  type  27  system  paromuter  statement  which  is  a  system  definition 
card  is  either  missing  or  out  of  sequence. 


Card  Type  27  priority  Code  thror 

Priority  01  is  reserved  for  an  operating  system.  Standard  priority  lor 
worker  routines  may  not  be  less  than  1  nor  gi'oater  than  99. 


Card  Type  27  Program  Kumber  Error 

Mb  <q>erating  system,  primary  worker  or  worker  or  worker  routine  may 
have  an  ID  that  is  less  than  1  or  greater  than  99. 


Card  Type  27-No  O^S  Program  Number 

There  mist  be  at  least  one  operating  system  named  in  an  S/P  type 
27  system  definition  statenent. 


Card  Type  27-Mcmory  Contiguity  Code  Error 

The  acceptable  code  nwibcrs  that  nay  bo  associated  with  tSiis  field  in 
the  S/P  system  definition  card  are  1  through  5.  Their  meaning  is  described 
in  the  system  paraiaotcrs  section  of  the  ttsers  manual  (refer  to  8^  card 
type  27). 


Card  Type  28  Missing 

An  8/P  Program  distribution  statement  is  required  and  is  either 
missing,  or  out  of  sequence. 

Card  Type  28  Program  Kumber  Creator  than  99 

A  simulation  model  limit  has  been  exceeded. 

Card  Tyne  29  CPU  Kuwbor  Croator  than  8 

A  ainulation  model  limit  has  been  exceeded. 

Cnrd  Type  wl  l.oad  Class  Oreatrr  than  18 

A  simulation  model  limit  has  01*00  exeeedtql. 
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Card  Type  28  DiiplicatP  Profrrtmi  Number 


A  redv.idanl  typo  ?.H  partimclcr  ha**  boon  rccclvod. 

Ko  Slreulntion  Con t  cl  Card 

A  •imulation  control  cuid  is  required  and  is  cither  Missing,  or  out 
of  sequence. 


Card  Type  32  Ci»U  ^^^allbcr  Error 

A  sinulation  model  limit  has  been  exceeded  by  referencing  a  CPU  nimber 
greater  than  5. 


Card  Typo  3d  Error 

An  8/P  tyi)C  34  0/S  mcuury  allocation  statement  is  either  missing,  Or 
out  of  sequence. 


Operating  System  and  Worker  Routine 
(SMI) 


0/S  and  t'/R  errors  will  cause  a  print  out  to  the  console  printer 
(pause)  and  continue  receiving  iiiptit*  Vlicn  an  error  is  detected  in  either 
an  operating  system  or  a  worker  routine,  the  rest  of  that  routine  will  tw 
by'pasKcd  and  the  next  routine  will  be  received.  Serious  errors  will 
prohibit  the  running  of  SMS.  )f  an  error  occurs  during  SMI  the  dump  control 
statement  la  disregarded  and  all  dump  tables  are  written  to  tape. 


20 1_ 

A  job  card  has  an  improper  card  code,  field  1  iwtsi  centain  the  numhor  SO, 
203 

The  first  card  (job  c^rd)  of  an  opx'-ratitq:  system  or  worker  routine*  does 
not  eont.'ln  an  FI  in  fic*d  3. 

tea 

A  aequerce  nu-^r  error  ha*  b<  i“n  found  in  the  job  card,  fi  id  3  must 
be  aero  ei*  blrnh 


i*T 


204 


Field  2  of  a  Job  card  contains  a  worker  routine  number  that  is  less 
than  1 . 


205 


Field  2  of  a  Job  card  contains  a  worker  routine  number  that  is  greater 
than  99. 


206 

Field  5  of  the  Job  card  contains  a  program  type  number  greater  than 
4,  the  permlssable  numbers  are  as  follows: 

1  =  0/S 

2  =  PA 

3  =  Commercial  W/R 

4  =  Scientific  W/R 


207 

Field  5  of  a  Job  card  contains  a  program  '.ype  number  less  than  1 
(see  error  206' . 


208 

Field  6  of  a  job  card  contains  a  load  Information  number  ’that  is  less 
than  1,  the  permlssable  numbers  are  as  follows: 


1  =  non'-reentrant 

2  =  reentrant 


209 

Field  6  of  a  job  card  contains  a  load  information  number  that  is 
greater  than  2. 


210 


Field  2  of  a  job  card  contains  a  worker  routine  number  for  which  there 
is  no  program  distribution  card  (S/P  card  type  25). 
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211 


Field  2  of  a  Job  card  contains  a  workei  routine  number  that  diq>licates 
one  already  received. 

212 

Field  1  of  an  ordinal  file  card  contains  a  number  other  than  80. 

213 

Field  2  of  an  ordinal  file  card  contains  a  worker  routine  number  that 
is  different  from  the  worker  routine  number  on  the  job  card. 

214 

Field  3  of  an  ordinal  file  curd  contains  a  sequence  number  other  than  0 
or  blank.  All  \¥/R  base  statements  must  have  a  sequence  number  of  0  or  be 
blank. 

215 

Field  t  of  an  ordinal  file  card  contains  a  real  f i Ig -gbinber  greater 
than  150. 

216  • 

Field  1  of  a  momory-1  card  contains  a  card  code  other  than  80. 

217 

Field  2  of  a  memory-l  card  contains  a  woj’ker  routine  number  that  does 
not  duplicate  the  worker  routine  number  of  the  job  card. 

218 

There  is  no  mcraory-l  card  in  the  worker  routine  base,  or.it  is  out  of 
sequence.  .  '  .  . 

219 

There  is  no  lo.'id  class  entry  (S/p  card  type  24)  to  indiente  which  CPU 
may  load  this  prop.rjun. 
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IIIJW  JJIWUIMI,; 


220 


There  are  no  floating  point  times  (C/D  card  type  02)  to  be  used  in 
performing  arithmetic  for  the  floating  point  fields  defined  in  the  UE^X)RY-2 
statement  (tf/R  card  type  84). 


221 

There  is  no  generate  statement  associated  with  this  operating  system 
or  worker  routine. 


222 


Field  2  of  the  generate  statement  contains  a  worker  routine  number 
that  docs  not  match  that  of  the  Job  card. 


223 


There  are  no  fixed  point  times  (C/D  card  type  02)  to  use  when  performing 
fixed  point  arithmetic  for  the  fixed  point  fields  defined  in  a  MEaK)Ry-2  state¬ 
ment  (W/R  card  type  84). 


224 

An  invalid  operation  code  has  been  detected  in  an  aperating  system  or 
wor^te^  routine. 


225 


A  statement  in  an  operating  system  or  a  worker  routine  contains  a 
worker  routine  number  in  field  2  that  does  not  coincide  with  the  worker 
routine  number  in  the  job  card. 


226 

An  operating  system  or  worker  routine  statement  has  been  read  which  has 
an  improper  sequence  number. 


227 

An  operating  svstem  or  worker  routine  statement  has  been  found  that 
addresses  a  statement  outside  the  limits  of  that  program. 
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228 


The  first  card  following  a  terminate  card  is  not  a  Job  card  or  an  end 
of  input  card  (card  code  99). 


Simulation  (SM2) 


The  following  is  a  list  of  diagnostics  produced  by  SM2  as  the  simulation 
model  is  being  run.  Two  types  of  errors  arc  detected  in  this  portion  of  the 
simulation  model.  The  first  type  is  serious,  and  in  addition  to  generating 
an  error  message,  will  terminate  the  simulation.  All  serious  errors  will  be 
identified  by  a  secondary  error  number  that  is  less  that  100.  The  second 
type  of  error  message  is  considered  precautionary  and  will  not  stvp  the 
running  of  the  simulation  model.  These  error  messages  will  have  a  secondary 
error  number  that  is  greater  than  100.  The  error  messages  produced  by 
SM2  will  consist  of  two  numbers,  the  first  number  identifies  the  sub¬ 
routine  that  detected  the  error  and  the  second  number  identifies  the 
specific  type  of  erroe  within  the  sub  routine.  57/1  is  an  example  of  the 
heading  of  a  serious  error.  14/101  is  an  example  of  a  precuationary  error 
message’s  heading. 

The  following  list  of  SM2  errors  is  ordered  by  subroutine  numbers. 

Certain  eri'ors  in  this  section  will  have  the  notation  (INTERNAL)  beside 
the  error  '.lumber.  Those  errors  will  Indicate  a  malfunction  of  the  simulation 
model  and  are  not  correctable  by  the  user.  In  the  event  that  an  INTERNAL 
error  should  occur,  the  user  is  requested  to  contact  the  simulation  model 
designers;  Leo  J.  Cohen  Associates,  334  West  State  Street,  Trenton,  New 
Jersey  -  609-695-1488. 


7/1 


An  attempt  has  been  made  to  transfer  to  a  fourth  nested  subroutine, 
the  limit  is  3. 


8/1 

An  EXIT  statement  has  been  encountered  for  which  there  is  no  return 
address. 


13/1 


A  MATH  statement  has  been  encountered  that  has  no  arithmetic  require 
wenls  in  any  of  its  three  parameters. 
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14/101 


The  execution  of  an  OPEN  statement  has  opened  a  file  that  is  already 

open. 


14/1 


An  attempt  has  been  made  to  execute  an  OPEN  statement  with  an  invalid 
I/O  code.  The  second  field  of  an  OPEN  statement  must  contain  a  1  to  signify 
an  input  file  or  a  2  to  signify  an  output  file. 


16/1 


An  attempt  has  been  made  to  terminate  a  worker  routine  whose  available 
transaction  (AT)  in  the  CPU  item  is  not  zero. 


31/1 


In  attempting  to  execute  a  MEMORY  Statement,  an  invalid  queue  number 
has  been  referenced. 


31/2 

In  attempting  to  execute  a  MEMORY  statement,  an  invalid  queue  type  has 
been  referenced.  The  queue  type  must  be  1,  which  represents  an  available 
transaction  (AT)  as  opposed  to  an  I/O  transaction . (lOT) . 

N 

31/3 


In  attempting  to  execute  a  MEMORY  statement,  a  memory  allocation  scheme 
as  defined  by  an  S/P  card  type  27  has  been  found  to  be  incorrect.  The  value 
of  this  field  must  fall  within  the  range  1-5, 


32/1 

An  attempt  has  been  made  to  execute  an  ALLOCATE  statement  without  first 
checking  if  there  is  memory  available,  A  MET^IORY  statement  mu.st  be  executed 

first. 


32/2 


An  attempt  has  been  mode  to  execute  an  ALI,0CATE  statement  without 
executing  the  PACK  statomont  before  attempting  the  allocation.  This  error 
indicates  that  the  KSI-i-1  relative  to  the  MEMORY  statement  did  not  transfer 
to  a  PACli  slntoment. 
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39/1 

An  attempt  has  been  made  to  select  a  zero  item  from  a  queue. 


39/2 

An  attempt  has  been  made  to  select  from  a  queue  whose  type  does  not 
match  the  first  parameter  of  SELECT  statement.  The  queue  type  is  designated 
by  an  S/P  card  type  23. 


39/3 

An  attempt  has  been  made  to  remove  an  AT  or  an  lOT  from  a  queue  when 
the  AT  word  or  the  JOT  word  in  the  CPU  item  was  not  empty. 


39/d 

An  attempt  has  been  made  to  associate  a  worker  routine  with  a  CPU 
that  is  not  capable  of  executing  that  woi’ker  rovitine.  This  error  is  a  resu! 
of  executing  a  SELECT  statement  without  first  executing  one  of  the  EXAMINE 
statements. 


40/101 

An  attempt  has  been  made  to  execute  a  BIFF  statement  for  a  file  that 
has  not  been  opened. 

41/1  (Internal) 

I0T«V  error.  Less  than  1  or  greater  than  900. 

41/2 

An  attempt  has  been  made  to  execute  an  lOREADY  statement  on  a  queue 
whose  t>-pe  indicates  that  it  docs  not  contain  lOTl's.  The  queue  typo  is 
defined  by  an  S/P  card  typo  23. 

42/3  (Internal) 

The  KTitf  item  is  less  than  1  or  greater  than  900.  This  error  can  also 
mean  that  the  queue  pointer  is  referencing  n  aero  filled  word  in  the  queue. 
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A 


42/4 


An  attempt  has  been  made  to  execute  an  lOREADY  statement  with  an  I/O 
transaction  item  of  z  :,’lds  is  a  result  of  not  performing  a  BUFF 

state)iient  prior  to  the  lOREAOY  statement.  It  is  the  BUFF  statement  that 
Indicates  to  the  simulation  model  that  an  I/O  transaction  item  is  to  bo 
generated  for  an  1/0. 


42/5  (Internal) 

Channel,  control  or  device  time  is  not  equal  to  zero. 


42/6  (Internal) 

Channel ,  control  of  device  number  is  not  zero. 


42 A  (internal) 

A  real  file  or  ordinal  file  number  is  zero. 


42^8 

An  attempt  has  been  made  to  execute  an  lOREADY  statement  where  the 
channel  number  is  zero.  This  is  a  result  of  incorrect  or  incomplete 
configuration  data  input  on  card  t>’pcs  9  and  10. 

S 


42/9 


In  attempting  to  execute  the  lOREADY  stotement  a  device  number  error 
has  been  found  in  the  function  table.  This  can  be  a  result  of  no  device 
being  specified  in  a  function  entry  (S/P  card  type  22),  an  invalid  function 
number  or  no  function  definition  card  being  entered  ns  input  data  (S/P  card 
typo- 22) . 


42/10 


In  attempting  to  execute  an  lOREADV  statement  a  device  number  error 
has  been  found,  ...Device .nvm’K  rF  r:v  ,t  .V  ir  t’lc  1  to  100  as  defined 

by  configuration  data  c.'trU  typo  5. 


43/1 


In  attomi>ting  to  execute  an  10AI>V.\.'>Ci.'  statotaonl  an  10  tran5iactJon  item 
whose  number  is  leas  tli:u^  1  or  greater  than  900  h”  been  encountered. 


43/2 


An  attempt  has  been  made  to  execute  an  lOADVANCE  statement  with  a  file 
number  of  zero. 


43/3  (Internal) 

lOADVANCE  statement  -  from  file  equals  zero. 


43/4 


In  attempting  to  execute  an  lOADVANCE  statement  it  has  been  found  that 
the  device  required  is  still  busy,  this  is  a  result  of  not  performing  ai; 
lOREADY  statement  fii’st. 


43/5 


An  attempt  has  been  made  to  perform  an  lOADVANCE  statement  without  first 
perfoi’mlng  an  10l{E^DY  statement. 


45/103  (Internal) 

Switch  set  to  zero. 


45/1 


A  reference  has  been  made  to  a  switch  number  greater  than  200. 


48/101 


In  executing  an  INTElinUPT  statement,  reference  has  b*;‘on  made  to  an 
undefined  Interrupt. 


48/1 


In  executing  an  INTEIPSWT  statement,  an  internipt  nu'iber  greater  thnn 
20  has  been  found. 


40/1 


An  atlejipl  has  been  made  to  execute  a  DISADbK  rt:vt' iu->nl  v  lth  an 
uiidcfincd  Interrupt. 
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S2/1 


An  attempt  has  been  made  to  execute  a  RE'TURN  statement  where  the  lOT 
word  in  the  CPU  item  Is  not  equal  to  zero. 


62/2 


An  attempt  has  been  made  to  execute  an  RFTURN  statement  where  the 
available  transaction  in  the  CPU  item  is  equal  to  zero. 


isa 

An  attempt  has  been  made,  in  executing  a  RETURN  statement,  to  return 
to  a  worker  routine  that  has  not  yet  been  loaded. 


82/4 

In  executing  a  RETURN  statement,  an  attempt  has  been  made  to  connect 
a  worker  routine  with  a  CPU  that  is  not  permitted  to  run  it.  This  is  a 
result  of  incorrect  or  inconpletc  data  in  the  S/P  card  typo  24,  card  type 
25,  or  card  type  28. 


83/1 


An  attempt  has  been  made  to  execute  an  ACTIVATE  statement  where  the 
AT  in  the  CPU  item  is  not  zero. 


84/1 


An  attempt  has  been  made  to  execute  a  RECEIVE  statement  where  the  AT 
in  the  CPU  item  is  not  zero* 


An  attempt  has  teen  made  to  execute  a  RECEIVE  statement  when  there  is 
no  newly  generated  tronsactioa  item  on  the  futuj’e  events  chain  to  bo  received. 


85/1 


An  attempt  has  boon  made  to  oxocuto  a  CYCLE  statement  when  the  AT  on  the 
CPU  item  is  not  zero. 
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55/2 


An  attempt  has  been  made  to  execute  a  CYCLE  statement  when  the  lOT  is 
in  the  CPU  item  is  not  zero. 


55/3 


An  attempt  has  been  made  to  execute  a  CYCLE  statement  without  all 
interrupts  being  enabled. 


56/1 


An  attempt  has  been  made  to  execute  a  DESTROY  statement  whore  the 
first  field  of  the  DESTUOY  statement  indicates  the  wrong  typo  of  transaction 
to  be  destroyed. 


56/2 


\n  attempt  has  been  made  to  execute  a  DESTROY  statement  where  the  AT 
is  to  be  destroyed  and  the  files  associated  with  that  AT  have  not  been 
closed. 


57/1 


An  attempt  has  been  r.ade  to  execute  a  PERlPilEPAL  statement  that 
specifics  a  queue  with  an  incorrect  queue  cqntrol  type  {S/P  Card  type  23). 
Queues  associated  with  a  PERIPIIER'^L  statement  must  have  a  queue  control  type 
of  1  (AT). 


57/2 


An  attoi^t  has  been  made  to  execute  a  PERIPlilltAl.  statement  with  a  queue 
parameter  whore  the  queue  pointer  references  a  zero  filled  word  in  the  quouo. 
This  can  be  the  result  of  referencing  an  incorrect  queue,  or,  not  hnving 
executed  an  EXAU  stuteincnt  first,  to  insure  that  the  queue  pointer  is 
referencing  a  pro|iar  word. 


(i  njenuil )  .  .  .  ,  . , .  .  ..  ...  .  v  » ■.  s 

Invalid  transaction  item  accessed  while  executing  a  PIltIPIIEItAL  statement. 


57/4  (Internal) 

Invalid  wordcr  routine  oddrcM-  encountered  whil*'  executing  a  I’litlPntiMt. 
atatou  utl . 
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57/s 

In  nttenpting  to  cxocutu  a  PETIPMEHAL  atatencnt,  an  invalid  file  vector 
•ddresa  has  been  encountered.  This  error  can  result  from  a  named  ordinal 
file  not  having  any  real  file  associated  with  it,  or  an  undefined  real  file. 


57/6  (Internal) 

Invalid  number  of  files  en^^ountcred  while  executing  a  PIAIPUERAL 
statement. 


aa. 


An  attOBf>t  has  been  made,  while  executing  a  PERIPH91AL  statement,  to 
reference  an  undefined  real  file. 


100/101 

A  worker  routine  has  aticippted  to  execute  an  (^crating  system  statement. 

100/102  g eternal ) 

Hon  existent  op'^codcs. 

100/3  Clnternnl) 

Internal  simulation  error. 


lOS^ 

The  future  event  a  chain  contains  more  than  200  i Ictus,  which  is  its 
limit.  In  order  to  correct  this  error,  the  simulation  must  bo  rtm  with  a 
different  and/or  smaller  worker  routine  mix,  ^ 


isia 

The  future  evmir-  chain  1*  Thert;  arc  no  iran-actl»»n  Item# 

moving  in  the  sii»uli»ti*v.r  erAU'i . 


The  future  events  chain  lit  cr|>ty.  Tht-re  are  no  tran«rction  items 
moving  in  the  slmulniion  aicdcl. 
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105/2 


The  future  events  chain  is  not  emttiy,  but  no  item  on  the  chain  can  be 
Moved  through  the  airoulation  model.  This  error  con  result  from  interrupts 
boing  ii4)roporly  disabled. 


l(»/3 


There  is  no  transaction  item  for  a  given  Ci>U  on  the  future  events  chain 
and  that  CPU  is  not  a  cycle  state. 


110/1 


An  atUtupt  has  been  Kuide  to  receive  an  interi'iipt  without  the  OOT  ord 
of  a  CI>U  item  being  r.cro. 


110/2  Qntcrnnl) 
Bud  KfiC  code. 


01  (li'Ununl) 

■'ieij'.liig  ID  «  B 

110/3  (Internal) 

a 

Controller  seixinj  ID,  not  lOT. 

110/4  (internal) 

Dc\‘ice  seising  ID  not  lOf 

110/5  (internal) 

Disrrepajtcy  in  real  file  number. 


201/1 

An  aHe*»|i\  h^s  been  unde  to  place  more  than  203  Tl  words  on  the  future 
events  chain.  To  negate  this  error,  the  slrttlniion  mhcI  »«r<l  be  rerun 
with  a  different  nnd/or  sswllrr  vwher  routine  wix. 
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201/2  (.IntcriviD 


Invalid  code,  FL'C. 

203/1 

The  .‘iimulali on  model,  in  attomptintj  to  generate  a  Jiew  transaction  item 
has  foinid  th:  t  the  limit  of  300  active  transaction  items  has  been  exceeded, 
to  correct  this  error,  the  simulation  must  be  rerun  witli  a  different  and/or 
smallc'i'  worker  routine  mix. 


204/1 

The  simulation  model,  in  attempting  to  generate  an  1/0  transaction 
item  has  found  that  the  limit  of  900  active  lOT's  has  been  exceeded.  To 
correct  this  error,. the  simulation  must  be  rerun  with  a  different  and/or 
smaller  worker  routine  mix. 
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INTRODUCTION 

The  following  is  a  description  of  tho  statistics  that  may  bo  requested 
by  the  STATISTICS  CONTROL  statement  and  the  SIMULATION  CONTROL  statement 
(system  parameters). 

The  following  information  is  common  to  the  description  of  tho  ten 
statistics  tables: 

1.  In  the  header  of  each  statistics  table  the  number  NNN  refers  to 
the  interval  during  which  that  statistics  table  was  developed. 

This  interval  is  controlled  by  the  first  parameter  of  the 
SIMULATION  CONTROL  statement  (system  parameters). 

2.  ST  number  N  in  the  header  associates  a  given  statistics  table 
with  one  of  the  ten. fields  in  the  STATISTICS  CONTROL  statement 

(system  parameters).  This  sytem  parameter  allows  the  user  to 
determine  which  statistics  tables  are  to  bo  dc'cloped  during  a 
simulation. 

3.  For  all  statistics  tables  whose  fields  contain  a  tine  value, 
that  value  will  be  given  in  minutes  and  hundredths  of  minutes. 

4.  For  all  statistics  tables  whoso  fields  contain  a  percentage 
value,  that  value  will  be  given  in  pcx-cent  and  hundredths  of  a 
percent. 

5.  Tho  statistics  for  a  given  interval  will  be  cimmlative.  There¬ 
fore,  the  final  sot  of  statistics  tables  will  be  developed  from 
Information  accumulated  during  the  entire  simulation. 


i 

! 

WORKER  ROUTINES  -  FINAL  RIPORT 


This  worker  routine  report  will  be  produced  at  tho  end  of  tho  simulation 
and  will  be  tho  final  statistics  tabic  developed. 


TOTxU.  V/R  THRU  SIMU.LATION 

This  field  will  specify  tho  total  number  of  worker  routines  tlv  I  were 
completed  dur.lng  a  simulntlon 

W/R  NU:.gif;H 

This  field  associates  the  follo-lng  Btatislics  vilh  a  part'  ul.nr  works,  i' 
routine. 
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TURNAUOUNI)  TIMI'; 


The  three  fields  associated  with  this  subheader  will  speficy  the 
minimum,  maximum  and  average  turnaround  time  for  this  woi'ker  routines 
transaction  items  during  a  simulation. 


CPU  TIME 


The  three  fields  as.soci a.tcd  with  this  subheader  will  specify  the 
minimum,  maximum  and  average  Cl’U  utilization  by  this  worker  routines 
transaction  items  during  a  simulation. 


NUMBER  T/1  GEinKRATED 

The  two  fields  associated  with  this  subheader  will  specify  the  number 
of  transaction  items  generated  and  the  average  for  this  worker  routine, 
relative  to  the  total  number  of  transaction  items  generated  during  a 
simulation.  • 


KUf.nU  R  lOT/1  Gi:>'KilATm 

The  three  fields  associated  with  this  subheader  Will  Specify  the 
minimum,  raxinu.m  and  average  number  of  1/0  transaction  items  generated  by 
this  worher  routine’s  transaction  items  during  a  simulation. 

NU.MBi'.q  1/0  OPERATIONS 


The  throe  fields  associated  with  tills  subh.c  ader  will  specify  the  mini¬ 
mum,  maximum  and  average  mimbcr  of  1/0  operations  that  were  completed  by 
this  worker  routines  transaction  items  during  a  .simul.Ttion, 


T/1  QUEUE  TIME 


The  three  fields  associated  with  Ihlr  subheader  will  specify  the  mini¬ 
mum,  maximum  and  overage  mtiibr  r  of  transaction  1  teni-s  that  were  queued  during 
a  simulation. 

I/O  QtiMiK  TIMK 

The  three  fj  uls  aKSi.;-i « tt  rt  with  this  *  ub’und.  r  will  specify  the  mini¬ 
mum,  maxltui  and  nvrr,i„e  of  J/U  transact  ic»n  it*'r'  -  that  vvre  queued 

dutlii;:  o  sir.  ulati«»n. 
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TRANSACl’ION  ITEM 


TRANSACTION  ITEM  NUMBER 


This  field  identifies  this  line  cf  statistics  with  a  particular  trans¬ 
action  item.  There  will  be  one  line  of  statistics  for  each  transaction 
item  that  was  active  to  this  time  interval. 


W/R  lDta<TlFl  CATION 


This  field  identifies  the  worker  routine  that  was  responsible  for 
the  generation  of  this  transaction  item. 


STATISTICAL  INTERVAli 


This  field  will  indicate  the  statistical  interval  with  which  these 
transaction  items  arc  ussociated. 


CREATE  TIME 


This  field  will  specify  the  creation  time  for  this  transiiction  item. 

TERtnXATE  TIME 

This  field  will  specify  the  terminatioh  time  for  this  transaction  item. 


CPU  TIME 

This  field  will  specify  the  amount  of  Q’U  Time  utilised  by  this  trans¬ 
action  item  durlnp,  its  course  throuch  the  simulator. 


10  QUWK  TIME 

This  field  will  specify  the  total  atwunl  of  liiK-  this  tranraction  item 
had  10  transactions  on  queues  durln-;  its  existence  in  the  simulation. 


0i»tX\TK»NS 

Tills  field  sill  S|*  cify  the  hiimIkt  of  1/0  ojjcrntlons  Ina-virated  by  this 
transnetlon  1  tei-  da.inj,  its  course  lhrou;.h  Iho  si  relator. 
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OPERATING  SYSTEM 


0/S  NU:.D^ER 


This  field  associntes  this  line  of  sitiitlBtics  with  one  operating 
system.  There  will  be  a  line  of  sti'tJslics  foe  each  operating  system 
rcprcKcntod  in  the  simulatioii. 


OVraUlEAD  TIME 


This  field  specific.',  the  opera  I  i  ji”  j.ystcms  ♦otal  overhead  time  to  this 
time  interval ^ 


I/O  TIME 


This  field  specific.^i  llie  total  I/O  time  associated  with  the  operating 
system  to  tltis  lime  Interval. 


P^•J1C^^’T  UTll.r/aTTON 

This  field  specific;  the  percentaj'.c  of  utilization  by  the  operating 
system  to  this  IIlc  intcivcl. 


lN'rK;:U:>T 

This  field  specific*  t!u  iiun1»>r  of  limes  Iniernipl  #1  wa.s  accc-s-scd  to 
this  lime  interval.  Thoie  vill  Ik*  20  filed;,  to  rcprc‘:ent  the  20  available 
interrupt;;.  Thor  c  Interrupl;;  that  have  bcoi  utili/cd  »ill  h.'»vc  values 
associated  »ith  them. 


Ql'I.TIK 


Qi  Kf?: 

TIiIn  field  i«'  ntifii."  ft'  li:u'  of  V  1  III  a  p.arU  t  ttl;i|-  f;\suc. 

There  till  Vv  a  lint  («•>  c-atfi  repj  i  -  t  r.li  »t  in  lli.-  Si  .a  t  n'O. 

Vil'E 


Till*  fl.'iil  cl'.i  ljt>.  t*l  l»'.  i'o.-  J»  1  -5  n  >  ■  i  II » ;•  I  ti  ji, 

this  ^eve*'. 
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METHOD' 


This  field  specifics  the  method  of  insertion  and  removal  of  transaction 
words  from  this  queue. 


MAXIMUM  ENTRIES 


This  field  specifics  the  maxiuunn  numlxir  of  entries  in  the  queue. 


CURRBtT  ENTR]  ES 


This  field  specifics  the  cui’rcnt  number  of  entries  in  the  queue. 


AVERAGE  BCTRllS 

This  fiwld  specifics  the  average  number  of  entries  in  the  queue. 


PERCENT  irniJ'/ATJON 

This  field  specifics  the  percentuge  of  utilization  of  the  queue  in 
entry/seconds , 


CENTRA].  PROCESSOR 


CPU  Nutaiir> 


This  field  identifies  a  Cl*U  with  this  line  of  statistics.  There  will 
be  a  lino  of  statistics  for  each  CI’U  represented  In  a  simulation. 


CVeu:  TIME 


Tills  field  spetlfios  viic  r-ounl  of  time  the  CPU  was  cycling  or  non-busy 
to  this  time  Interval. 


0/S  TIME 


Tills 
oprrati n- 
tltK*. 


field  the  ai«ow:il  of  tlt.c  the  CPU  spent  w.-^nipulutint:  tho 

sy?ite®(f.)  to  thi»-  lira?  interval.  Thli^  cm  t»c  coti'-tderc<i  over!io»d 


f.r  ?  >. 


PERCKNT  UTILIZATION 

This  field  specifics  the  percentage  of  time  a  CPU  was  busy  to  this 
time  interval. 

PERCRKT  OVfcRllRAD  TIME 

This  field  specifics  the  percentage  of  time  the  CPU  was  busy  doing 
work  for  the  operating  system  to  this  time  interval, 

IIEMORY 

in^lT 

This  field  associates  this  line  of  statistics  v/ith  a  given  memory. 
There  will  bo  a  lino  of  statistics  for  every  memory  represented  in  the 
simulation. 

PACKS 

This  field  will  specify  the  total  number  of  times  a  PACK  statement  was 
applied  to  tiiis  memory,  to  this  time  internal. 

NO  MEMORY 

This  field  specific^,  the  total  number  of  times  the  NO  METDRY  exit  was 
taken  from  the  UC^X)!lY  statement  (0/S  card  t)pc  31)  to  this  time  interval. 

cuKRi^’T  pac.f:s  busy 

This  field  specifies  the  number  of  pages  busy  at  this  time  interval. 

AVKU.ACK  PAGIS  RUSY 

This  field  specifics  the  average  number  of  pages  associated  with  this 
memury  that  were  busy  to  this  tine  interval. 

p»yK\T  irrii.|y  \Tiox 

This  field  tpccllics  the  pcrce'>ta;;c  of  utilixation  of  this  mermry  to 
this  lime  interval  in  pagrs/?rcond?- . 
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CX>N’rROL 


COHTROL  miDKR 

This  field  identillos  one  line  of  stalistlcs  withe’s  control.  There 
will  bo  a  statistics  line  for  each  control  represented  in  the  slmulntion. 


TOTAL  USE  TIME 

This  field  specifies  the  total  useage  time  of  a  control  unit  to  this 
time  interval. 


PBRCEMT  USE  TIME 

This  field  specifies  the  percentage  of  useage  for  a  control  unit  to 
this  time  interval. 


CHANNEI. 


QiANNH,  Nur.mwt 

This  field  associates  a  channel  with  this  line  of  statistics.  Tlicrc 
will  be  a  line  of  statistics  for  each  channel  represented  in  a  simulation. 

S 

TOTAl.  USE  TIME 


This  field  specifies  the  total  useage  time  for  the  channel  to  this 
time  interval. 


PCTCSNT  UTlLlZATlCg; 

This  field  specifies  the  percentage  of  tine  that  the  channel  was  used 
to  this  tlHC  interval. 


AVDiACK  TKANSKiJ:  ir.Tr 


This  field  specific?,  the  average  transfer  Cor  this  channel  to  this 

tine  interval. 
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DEVICE 


DEVICE  MIMUEK 


This  field  identifiors  a  device  with  the  information  that  follows. 
There  will  be  a  line  of  statistics  for  each  device  represented  in  a 
simulation. 


TOTAL  SEEK  TIME 


This  field  specifics  the  total  amount  of  seek  time  associated  with  the 
device  to  this  time  interval. 

PERCENT  SEEK  TIME 


This  field  specifier,  the  porcentase  of  seek  time  associated  with  the 
device  to  this  time  interval. 


TOTAL  USE  TIME 

This  field  specifics  the  total  amount  of  usenge  time  for  the  device 
to  this  time  Intirval. 


PERCm  USE  TIME 

This  field  specifies  the  pcrccnt;»;’.e  of  time  the  device  was  used  to 
this  time  interval. 


FILE 


-:At,  FIl .E  KU’.r.EK 

This  field  identifies  one  line  of  statistics  with  the  real  file  number. 
File  Stnlirtics  vill  occur  for  each  flic  represented  in  a  simulation. 


UIA'ICK  Kl'^nthU 

This  field  specifit  '  th>,-  device  in*  Ivi  with  which  the  real  file  is 
associated. 


Rta^TlVK  I/>CM  I  ON 

This  ficlii  sp.riflv.'  th*-  J«k'  ,•  1 5 on  oa  th  -  d.viec  of  the  i  cnl 


c-r* 


file 


TOTAL  SaZE  TIME 


ThiB  field  specifics  the  totiil  amount  of  time  that  the  file  was  seized 
to  this  time  interval. 


PERCENT  SEIZE  T1  ME 


This  field  specifies  the  percentnee  of  seize  time  associated  with  the 
file  to  this  time  interval. 


READ  WRITE  TIME 

This  field  specifies  the  total  amount  of  time  n  file  was  reading  or 
writing  to  this  time  interval. 


PERCENT  RK\D  If  RITE  TIME 


This  field  specifies  the  percentage  of  time  a  file  was  reading  or 
writing  to  this  time  interval. 


pERCEtT  USE  T1.MK  SEEKING 

This  field  specifics  the  percent  of  use  lime  spend  seeking  to  this 
time  interval. 


PERCENT  USE  Pg^Al.TY 

Tnis  field  r-pccifles  the  percent  of  use  time  that  was  a  result  of 
penalty  tiste  to  this  time  interval. 


TOTAL  PENAl.TY  TIMK 

Thl  field  specifics  the  total  amount  of  penalty  lijut  associated  *ith 
this  dovico  (i *  -ny)  to  this  lime  interval. 


ProCECT  >’E:AI.TY  TIME 

This  field  specifics  the  pcjccnlrge  of  penalty  tit’c  (ti  any)  a’-?oclelvct 
wil^  this  device  to  this  lir.<'  Interval. 
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WORKING  PAPER 


APPENDIX  D 


tlSBl^S  MANUAL 
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Future  Events  Chain  Table  Dumi 


The  Future  Events  Chain  Table  Dump  provides 
a  detailed  printout  of  each  entry  on  the  future  events 
chain.  For  a  detailed  description  of  the  entries  found 
in  the  future  events  chain  table,  reference  the  descrip 
tion  of  Tl. 

ENTRY 

The  ENTRY  field  contains  the  number  of  the 
currerit  entry  in  the  future  events  chain. 

COPE 

The  CODE  field  contains  the  code  associated 
with  the  current  future  eventr.  chain  item.  All  of 
the  possible  future  events  chain  codes  are  provided 
in  the  description  of  Tl . 

ITEM 

The  ITEM  field  contains  the  number  of  the 
item  whiv'h  occupies  this  entry  on  the  future  events 
chain.  The  manner  in  which  future  events  chain  items 
are  referenced  is  covered  completely  in  the  description 


CPU  Item  Dump 


The  CPU  Item  Dump  contains  all  of  the  inform¬ 
ation  maintained  during  the  simulation  for  each  CPU. 

The  arrangement  of  this  information  in  the  memory  of 
the  simulating  computer  may  be  found  in  the  description 
of  Tl. 

COT 

The  COT  field  contains  the  number  of  the 
first  entry  for  the  current  operating  transaction  in 
the  transaction  item  table  dump.  The  current  status 
of  the  COT  may  be  determined  by  examining  the  trans¬ 
action  item  dump. 

The  AT  field  contains  the  number  of  the  first 
entry  in  the  transaction  item  table  dump  for  the  avail¬ 
able  transaction.  The  current  status  of  the  available 
transaction  may  be  determined  by  examining  the  trans¬ 
action  item  table  dump. 
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Ihe  lOT  field  contains  the  number  of  the 


current  10  transaction  item  which  may  be  found  in  the 
10  transaction  item  table. 

0/S  PROGRAM 

The  0/S  PROGRAM  field  contains  the  number  of 
the  worker  routine  which  will  be  used  as  the  operating 
system  for  this  CPU.  The  number  in  this  field  is  also 
the  number  of  the  entry  in  the  worker  routine  base 
table  for  the  operating  system  for  this  CPU. 

MEMORIES 

The  column  headed  MEMORIES  contains  a  list 
of  the  memories  which  are  usable  by  this  CPU.  Although 
the  column  contains  twenty  entries  the  maximum  number 
of  memories  which  may  be  attached  to  any  CPU  is  ten. 

The  numbers  contained  in  this  column  point  to  entries 
in  the  memory  table . 

CHANNELS 

The  column  headed  CHANNELS  contains  a  list 
of  the  channels  which  may  be  accessed  by  this  CPU. 


This  channel  nunber  contained  in  this  column  are  internal 


channel  numbers  and  may  not  correspond  to  the  external 
channel  numbers.  Each  of  the  entries  in  this  column 
point  to  an  entry  in  the  channel  table.  It  is  i^x>rtant 
to  remeiid>er  that  while  selector  channels  only  required 
one  entry  in  the  channel  table,  multiplexor  channels 
required  two  entries  in  the  channel  table.  For  this 
reason,  the  channel  table  numbers  may  skip  an  occassional 
entry. 

INTERRUPT -ADDR 

The  INTERRUI  J  ADDRESS  column  contains  a 
pointer  to  the  statement  in  the  statement  table  which 
will  be  executed  for  each  of  the  twenty  possible 
interrupts  for  this  CPU.  Therefore,  the  first  entry 
corresponds  to  interrupt  number  1,  the  second  entry 
corresponds  to  interrupt  number  2,  and  so  on. 

INTERRUPT -CTR 

The  column  headed  INTERRUPT  COUNTER  contains 
a  count  of  the  number  of  times  each  of  the  twenty 
possible  interrupts  occurred  during  the  running  of 
this  siwilation.  Each  interrupt  count  corresponds  to 
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the  interrupt  ehose  first  address  in  the  operating 
8yste«  is  given  by  the  entry  in  the  interrupt  address 
coluan. 

CPU  DEFINITION 

The  two  coluans  headed  CPU  DEFINITION  list 
each  of  the  fields  froa  the  two  CPU  definition  cards 
used  to  define  this  CPU.  Since  the  field  used  to 
define  a  CPU  aay  be  contained  within  the  siaulator  in 
either  floating  point  or  fixed  point  format,  Xvto  columns 
are  used  to  print  these  values.  Fields  maintained  in 
fixed  point  foraat  will  be  printed  in  the  left  column, 
and  fields  maintained  in  floating  point  format  will  be 
printed  in  the  right  column. 

FIXFJ)  POINT  TABUE 

The  two  columns  entitled  FIXED  POINT  TABLE 
contain  the  four  pairs  of  entries  which  were  defined 
as  the  fixed  point  table  in  the  CPU  definition  card. 
FLXtATING  POINT  TABLE 

The  two  columns  headed  FUWING  POINT  TABLE 
contain  the  three  pairs  of  entries  which  were  defined 
as  the  floating  point  table  in  the  CPU  definition  card. 
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CLOCK  ITEM  TABLE 


The  CLOCK  ITEM  TABLE  field  contains  the  tiae 
in  aicroseconds  at  which  the  next  clock  interrupt  will 
occur. 

TOTAL  OPERATING  SYSTEM  TIME 

The  TOTAL  OPERATING  SYSTEM  TIME  field  contains 
the  total  aaount  of  tiae  which  has  been  charged  to 
operating  systea  transactions  working  for  this  CPU. 

This  value  is  expressed  in  aicroseconds . 

TOTAl.  OPERATING  SYSTEM  lOT  QtJEUE  TIME 

The  TOTAL  OPERATING  SYSTEM  lOT  QUEUE  TIME  is 
the  total  amount  of  time  10  transaction  items  generated 
by  the  operating  system  spent  on  queues.  This  field 
is  expressed  in  microseconds. 

TOTAL  OPERATING  SYSTEM  TI  QUEUE  TIME 

The  TOTAL  OPERATING  SYSTEM  TI  QUEUE  TIME 
field  contains  the  total  amount  of  time  operating 
system  transaction  items  spent  on  any  queue  in  the 
system.  This  field  is  expressed  in  microseconds. 
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TOTAL  OrERATIWG  SYSTEM  CYCLE  TIW 


Th«  TOTAL  OPBRATIMG  SYSTEM  CYCLE  TIME 
•xpzcsscs  in  alczoscconds  the  total  asount  of  tine 
this  CPU  spent  cycling. 

OIBSOW  MIX  TIME 

The  GIBSON  MIX  TIME  field  expresses  the 
average  instruction  tine  for  COMPUTE  stateaents 
executed  in  this  CPU. 
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Transaction  Item  Table  Dximp 


The  Transaction  Item  Table  Duiq>  contains 
the  current  status  lot  each  active  transaction  in 
the  simulator.  Each  transaction  item  requires  a 
■inimui  of  three  entries  in  the  transaction  item 
table.  In  addition,  for  every  seven  ordinal  files 
after  the  first  seven  an  additional  entry  will  be 
required  in  the  transaction  item  table.  Each  of 
the  possible  fields  in  a  transaction  item  is  defined 
below.  For  a  complete  description  of  the  memory  layout 
of  a  transaction  item  in  the  simulating  computer^ 
examine  the  description  of  T4. 

NUMBER 

The  NUMBER  field  contains  the  number  of  the 
entry  in  the  transaction  item  table  which  is  being 
printed  on  a  current  line. 

W/R 

The  W/R  field  contains  the  number  of  the  worker 
routine  for  which  the  current  transaction  is  being  run. 
Ttiis  field  points  to  the  entry  in  the  worker  routine  base 


table. 


PILB 


The  PILB  field  contains  the  value  of  the 
cturrent  ordinal  file  request  for  this  trauisaction. 

ID 

The  ID  field  contains  the  identification 
nuaber  for  the  current  transaction  itea.  This  field  is 
in  the  foraat  VfWNNNN,  where  VIW  is  the  worker  routine 
nuaber  and  NNNN  is  the  sequence  nuaber  of  this 
transaction. 

RUN 

The  RUN  field  contains  a  zero  if  the  current 
transaction  has  not  had  aeaory  allocated  to  it.  If 
this  field  is  not  zaro  it  ^.untains  a  pointer  to  the 
run  class  table  entry  controlling  the  CTO's  which  aay 
execute  this  transaction. 

PRl 

The  PRl  field  contains  the  priority  of  the 
current  transaction. 

NSI 

The  N51  field  rontains  the  address  of  the 
next  sequential  instruction  to  be  executed  b^  this 
transaction  In  the  statenent  table. 


lOT 


The  lOT  field  contains  a  count  of  the  nuaber 
of  10  transaction  items  outstanding  for  this  trans¬ 
action. 

TYPE 

The  TYPE  field  contains  a  code  which  defines 
the  current  transaction's  program  type.  In  ordinal 
sequence,  the  type  code  defines  the  current  transaction 
as:  1.  An  operating  system.  2.  A  primary  worker. 

3.  A  commercial  worker.  4.  A  scientific  worker. 

CPU 

The  CPU  field  contains  the  number  of  the 
CPU  which  was  last  used  to  advance  time  for  the 
current  transaction. 

LA-1  LC-1 

The  LA-i  LC-1  fields  contain  the  first  loop 
address  and  first  loop  counter  for  the  cu .rent  trans¬ 
action  item. 

LA-2  LC-2 

The  LA-2  LC-2  fields  contain  the  second  loop 
address  and  second  loop  counter  for  the  current  trans¬ 
action  Eem. 
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LA-3  U:-3 


Th«  LA-3  lJC-3  fields  contain  the  third  loop 
address  and  loop  counter  fields  for  the  current  trans¬ 
action  itea. 

SA-1 

The  SA-1  field  contains  the  subroutine  exit 
address  for  the  lowest  level  of  subroutines.  The  SA-2 
and  SA-3  field  contain  the  second  and  third  subroutine 
exit  addresses,  respectively. 

T-P 

The  T-P  field  contains  the  nuaber  in  the 
transaction  itea  table  for  the  tiae  entry  of  the' 
current  transaction. 

F-P 

The  F-P  field  ccntains  the  niwber  in  the 
transaction  itea  table  for  the  first  file  section  of 
the  current  transaction. 

CREATION  TIMS 

The  CREATION  field  contains  the  tiae 

expressed  in  aicroseconds  at  which  the  current  trans¬ 
action  itea  was  either  received  or  activated. 
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TIME  OFF  FEC 


The  TIME  OFF  FEC  field  contains  the  time 
expressed  in  microseconds  at  which  the  current  trans¬ 
action  is  due  off  the  future  events  chain  if  it  is 
currently  on  the  future  events  chain. 

ADVANCE  TIME 

The  ADVANCE  TIM£  field  contains  the  total 
amount  of  time  expressed  in  microseconds  which  the 
current  transaction  must  spend  on  the  future  events 
chain  before  the  next  sequential  instruction  may  be 
executed . 

TOTAL  CPU  TIME 

The  TOTAL  CPU  TIME  field  contains  a  total 
of  all  of  the  advance  times  executed  by  the  current 
transaction.  The  total  CPU  time  field  is  expressed 
in  microseconds, 

TI  QUEUE  START 

The  TI  QUEUE  ST^PT  field  contains  the  total 
amount  of  time  expressed  in  microseconds  which  the 
current  transaction  item  has  spent  on  queues. 
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lOT  TOTAL  QUEUE 


Tne  lOT  TOTAL  QUEUE  field  contains  the  total 
amount  of  time  expressed  in  microseconds  which  10 
trans^iction  items  generated  by  this  transaction  item 
have  spent  on  queues. 

B-n 

The  B-n  field  contains  the  count  of  the 
number  of  buffers  available  for  the  ordinal  file 
expressed  by  n. 

R-n 

The  R-n  field  contains  a  count  of  the  number 
of  records  available  in  the  current  buffer  for  the 
ordinal  file  expressed  by  n. 

T-n 

The  T-n  field  contains  a  count  of  the  total 
number  of  10  operations  pe>'formed  for  the  ordinal  file 
expressed  by  n.  If  the  value  contained  by  this  field 
is  negative,  the  file  defined  is  closed.  If  the  value 
contained  by  this  field  is  positive  the  file  expressed 
by  n  is  opened. 
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I  /O  Tran  sac  t  ion  I  tern  Dum; 


The  10  Transaction  Item  Dump  gives  a  printout 
of  each  10  transaction  item  which  is  active  at  the 
current  moment  in  the  simulation.  For  a  description 
of  the  actual  layout  of  each  field  in  an  10  transaction 
item  in  the  memory  of  the  simulating  computer  examine 
the  description  of  T4. 

ITEM 

The  ITEM  field  contains  the  number  of  the 
current  entry  in  the  10  transaction  item  table. 

TI  NUMBER 

The  TI  NUMBER  field  contains  the  number  of  the 
entry  in  the  transaction  item  table  which  generated  this 
10  transaction  item, 

FEC 

The  FEC  field  contains  a  count  of  the  number 
of  times  a  pointer  to  this  10  transaction  item  appears 
on  the  future  events  chain, 

TYPE 

The  TYPE  field  contains  a  code  which  describes 


the  current  10  transaction  item  type. 


CPU 


The  CPU  field  contains  the  number  of  the 
CPU  which  was  used  to  generate  this  10  transaction 
item. 

Si 

The  CH  field  contains  the  number  of  the 
channel  which  is  being  used  by  this  10  transaction 
item. 

CTL 

The  CTL  field  contains  the  number  of  the 
control  unit  which  is  being  used  by  this  transaction 
item. 

DEV 

The  DEV  field  contains  the  number  of  the 
device  which  is  being  used  by  this  lO  transaction 
item. 

R.  F. 

The  R.  F.  field  contains  the  number  of  the 
real  file  for  which  this  lO  transaction  item  was 
generated . 
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0.  F 


The  0.  F.  field  contains  the  number  of  the 
ordinal  file  for  which  this  10  transaction  item  was 
generated . 

F.# 

The  F.#  field  contains  the  function  number, 
if  any,  for  which  this  10  transaction  item  was  gen¬ 
erated. 

CHANNEL  END 

The  CHANNEL  END  field  contains  the  time  at 
which  the  channel  being  used  by  this  10  transaction 
item  will  be  released. 

CONTROL  END 

The  CONTROL  EinD  field  contains  the  time  at 
which  the  control  unit  being  used  by  this  10  trans¬ 
action  item  will  be  realesed. 

DEVICE  END 

The  DEVICE  END  field  contains  the  time  at 

t 

which  the  device  being  used  by  this  10  transaction 
item  will  be  released. 
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QUEUE  START 


Ihe  QUEUE  START  field  contains  the  tine  at 
which  the  current  10  transaction  item  was  placed  on  any 
queue, if  it  is  currently  on  a  queue. 


The  TOTAL  QUEUE  field  contains  the  total 


amount  of  time  spent  by  this  10  transaction  item  on 


any  queue  in  the  system. 
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Worker  Routine  Base  Table  Dump 


The  Worker  Routine  Base  Table  Dump  describes 
each  of  the  entries  being  used  in  the  worker  routine  base 
table.  For  a  description  of  how  each  of  the  fields  on 
these  entries  are  laid  out  in  the  memory  of  the  sim¬ 
ulating  computer  examine  the  description  of  T5. 

NUMBER 

The  NUMBER  field  contains  the  number  of  the 
current  entry  in  the  worker  routine  base  table. 

SPREAD 

The  SPREAD  field  contains  the  creation  interval 
for  the  generation  of  transactions  associated  with  this 
worker  routine. 

LIMIT 

The  LIMIT  field  defines  the  total  number  of 
transactions  which  are  to  be  generated  for  this  worker 
routine . 

GEN 

The  GEN  field  contains  a  count  of  the  total 
number  of  transactions  generated  for  this  worker  routine. 
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LOAD 


The  LOAD  field  contains  a  pointer  to  the 
load  class  table  which  describes  the  CPU's  capable  of 
loading  the  current  worker  routine. 

PRI 

The  PRI  field  describes  the  priority  of  any 
transaction  created  for  the  current  worker  routine. 

FST  INST 

The  FST  INST  field  contains  the  number  of 
the  first  statement  in  the  statement  table  which  will 
be  executed  by  any  transaction  generated  for  the 
current  worker  routine. 

CODE 

The  CODE  field  contains  a  code  which  describes 
whether  the  current  worker  routine  is  reentrant  or  not. 
TYPE 

The  TYPE  field  describes  the  current  worker 
routine  type.  The  worker  routine  types  in  ordinal 
sequence  are: 

1.  Operating  system. 

2.  Primary  worker. 

3.  Commercial  worker. 

4.  Scientific  worker. 
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NUMBER  OF  TI 


The  NUMBER  OF  TI  field  contains  a  count  of 
the  number  of  transaction  items  currently  in  memory 
for  the  current  worker  routine. 

CPU 

The  CPU  field  contains  the  number  of  the 
CPU  for  which  a  RECEIVE  interrupt  is  to  be  generated 
when  a  transaction  item  comes  off  the  future  '•vents 
chain  for  the  first  time. 

FILES 

The  FILES  field  contains  a  count  of  the  total 
number  of  files  associated  with  the  current  worker 
routine, 

LOG 

The  LOC  field  contains  a  pointer  to  the  entry 
in  the  file  vector  table  which  contains  the  description 
of  the  first  ordinal  file  for  the  current  worker  routine. 
Ordinal  files  are  then  described  in  sequence  in  the  file 
vector  table  up  to  the  total  number  of  ordinal  files 
defined  for  the  current  worker  routine. 
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INST  STOR 


The  INST  ST(Ml  field  describes  the  total 
nueber  of  pages  of  instruction  storage  required  for 
the  current  worker  routine. 

DATA  STOR 

The  DATA  STOR  field  describes  the  total  number 
of  pages  required  for  data  by  the  current  worker  routine. 
1/0  STOR 

The  I/O  STOR  field  describes  the  total  number 
of  pages  of  I/O  storage  required  by  the  current  worker 
routine. 

CALL 

The  CALL  field  contains  a  count  of  the  total  . 
number  of  transactions  generated  by  a  CALL  for  the 
current  worker  routine. 
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File  Vector  Table  Dump 


The  File  Vector  Table  Dump  contains  a  des> 
cription  of  each  entry  in  the  file  vector  table.  The 
file  vector  table  contains  a  description  of  each 
ordinal  file  used  by  any  worker  routine  in  the  current 
simulation.  The  first  entry  in  the  file  vector  table 
for  the  ordinal  files  of  a  specific  worker  routine  is 
given  by  the  LX3C  field  in  the  worker  routine  base  table. 
For  a  description  of  the  actual  field  layouts  in  the 
memory  of  the  simulating  con^uter  examine  the  des¬ 
cription  of  T6. 

ENTRY 

The  ENTRY  field  contains  the  number  of  the 
entry  in  the  file  vector  table  being  described. 

FILE 

The  PILE  field  contains  the  number  of  the 
real  file  to  which  the  ordinal  file  is  assigned. 

BUFFERS 

The  BUFFERS  field  contains  a  count  of  the 
number  of  buffers  which  are  to  be  assigned  to  this 
ordinal  file  for  the  worker  routine. 
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C  field  contains  the  seizing  code 
specified  in  the  ordinal  file  card  for  this  file. 
The  three  possible  entries  in  this  field  are  seize 
nothing,  seize  the  file,  and  seize  the  file  and 


device. 


Memory  Table  Dumj 


The  Memory  Table  Dump  prints  a  description 
of  each  entry  in  the  memory  teble.  There  is  one  entry 
in  the  memory  table  for  each  memory  described  in  the 
current  simulation.  For  a  description  of  the  actual 
field  layout  in  the  memory  of  the  simulating  computer 
examine  the  description  of  T7. 

MEMORY 

The  MEMORY  field  contains  the  number  of  the 
current  memory  table  entry. 

LOW  PAGE 

The  LOW  PAGE  field  contains  the  number  in 
the  page  table  of  the  first  page  contained  in  this 
memory . 

HIGH  PAGE 

The  HIGH  PAGE  field  contains  the  number  of 
the  last  page  in  the  page  table  for  this  memory. 
NUMBER  PACKS 

The  NUMBER  PACKS  field  contains  a  count  of 
vhe  number  of  times  a  park  instruction  mas  executed 
for  the  current  memory. 


NUMBER  NO  MEI-DRY 


The  NUMBER  NO  MENDRY  fit  Id  contains  a  count 
of  the  number  of  times  a  no  memory  exit  line  was 
taken  from  the  MEMORY  statement  whi  referencing 
this  memory. 

PAGES  BUSY 

The  PAGES  BUSY  field  contains  a  count  of  the 
current  number  of  pages  busy  in  this  memory. 

LAST  REFERENCE  TIME 

The  LAST  REFERENCE  TIME  field  contains  the 
last  time  at  which  the  number  of  pages  busy  in  this 
memory  was  altered. 

MEMORY  LOAD 

The  MEMORY  LOAD  field  contains  a  total  of 
the  number  of  page  microseconds  which  have  been  used 
for  the  current  memory  up  to  the  last  reference  time  . 
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The  Page  Table  Dump  prints  a  description  of 
each  entry  in  the  page  table.  For  a  description  of 
the  codes  used  in  the  page  table  refer  to  the  des¬ 
cription  of  T8. 

PAGE 

The  PAGE  field  contains  the  number  of  the 
page  being  described  by  the  current  entry. 

21 

The  TI  field  contains  the  number  of  the 
transaction  item  or  worker  routine  base  which  has 
seized  the  current  page  if  the  current  page  is  busy. 


Load  Class  Table  Dump 


ihe  Load  Class  Table  Dump  describes  each 
entry  in  the  load  class  table  being  used  by  the 
current  simulation.  For  a  description  of  the  organ¬ 
ization  of  the  load  class  table  in  the  memory  of  the 
simulating  computer  reference  the  description  of  T9. 
CLASS 

The  CLASS  field  contains  the  number  of  the 
entry  in  the  load  class  table  being  described  on  this 
line. 

li  ' 

The  TI  field  contains  the  value  of  the  entry 


■numbered  N. 


Run  Class  Table  Dump 


The  Run  Class  Table  Dump  describes  each  of 
the  entries  in  the  run  class  table  described  for  the 
current  simulation.  For  a  complete  description  of  the 
organization  of  the  run  class  table  reference  the 
description  of  TIO. 

CPU 

The  CPU  field  contains  the  number  of  the 
loading  CPU  for  which  the  current  entry  is  to  be  used. 

II 

The  TI  column  contains  the  value  of  the 


entry  numbered  N. 


Queue  Table  Dump 

The  Queue  Table  Dump  describes  the  entry 
for  each  queue  defined  in  the  current  simulation. 

For  a  complete  description  of  the  queue  tables 
reference  the  description  of  T12. 

QUEUE 

The  QUEUE  field  contains  the  number  of  the 
queue  which  the  current  entry  describes. 

QUEUE -START 

The  QUEUE-START  field  contains  the  number 
of  the  first  entry  in  the  queue  entry  table  for  the 
current  queue.  , 

QUEUE  END 

The  QUEUE  END  field  contains  the  number  of 
the  last  entry  in  the  queue  entry  table  for  the  current 
queue . 

QUEUE  POINT 

The  QUEUE  POINT  field  contains  the  number  of 
the  entry  in  the  queue  entry  table  which  is  currently 
being  referenced  in  this  queue. 
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ENTRY 


The  ENTRY  field  contains  a  code  which  deter¬ 
mines  whether  transaction  items  or  10  transaction 
items  may  be  placed  in  this  queue.  A1  indicates  the 
queue  contains  transaction  items,  and  A2  indicates 
the  queue  contains  10  transaction  items. 

METHOD 

The  METHOD  field  contains  a  code  which 
indicates  whether  the  queue  is  organized  in  a  priority, 
FIFO,  or  LIFO  method. 

MAXIMUM 

The  MAXIMUM  field  contains  a  count  which 
indicates  the  maximum  number  of  entries  which  the  queue 
contained  at  any  time  during  the  current  simulation. 
CURRENT 

The  CURRENT  field  contains  a  count  of  the 
current  number  of  entries  contained  by  this  queue. 

LAST  REFERENCED  TIME 

The  LAST  REFERENCED  TIME  field  contains  the 
time  at  which  the  number  of  entries  contained  by  this 
queue  was  last  altered. 
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QUEUE  LOAD 


The  QUEUE  LOAD  field  contains  the  total 
number  of  entry-microseconds  accumulated  for  this 
queue . 
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Queue  Entry  Table  Dump 


The  Queue  Entry  Table  Dump  provides  a 
printout  of  the  contents  of  each  entry  for  all  of 
the  queues  described  in  the  current  simulation.  For 
a  detailed  description  of  the  queue  entry  table  contents 
reference  the  description  of  T13. 

ENTRY 

The  ENTRY  field  contains  the  number  of  the 
queue  entry  whose  contents  is  shown  under  the  heading 
ITEM. 

ITEM 

The  ITEM  field  contains  a  printout  of  the 
value  of  the  entry  whose  number  is  shown  on  the  left. 
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File  Set  Table  Dvunp 


The  File  Set  Tabic  Dump  provides  a  printout 
for  each  real  file  described  in  the  current  simulation. 
For  a  detailed  description  of  the  contents  o^  the  file 
set  table  reference  the  description  of  T14. 

REAL  FILE  NUMBER 

The  REAL  FILE  NUMBER  field  contains  the 
number  of  the  real  file  being  described. 

SEIZING  ID 

The  SEIZING  ID  field  contains  the  number 
of  the  transaction  item,  if  any,  which  has  seized  the 
current  real  file. 

DEVICE  r^UMBER 

The  DEVICE  NUMBER  field  contains  the  number 
of  the  device  on  which  this  real  file  resides. 

REL-LOC 

The  REL-LOC  field  contains  the  relative 
location  number  of  this  real  file  on  the  device 
specified. 

BUF-LEN 

The  BUF-LEN  field  contains  the  length  of 
the  buffer  required  to  read  from  or  write  to  the  real 
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file  specified. 

REC 

The  REC.  field  contains  a  count  of  Ihe  number 
of  records  contained  in  each  buffer  for  the  current 
real  file. 

SIZE 

The  SIZE  field  contains  the  count  of  the 
total  number  of  blocks  contained  in  the  current  real 
file. 

LAST-TIME-SEIZED 

The  LAST-TIME-SEIZED  field  contains  the  time 
expressed  in  microseconds  at  which  this  real  file  was 
last  seized. 

TOTAL-TIME-SEIZED 

The  TOTAL-TIME -SEIZED  field  contains  the  total 
number  of  microseconds  for  wbich  this  file  has  been 
seized  during  the  current  simulation. 
TOTAL-READ-WRITE-TIME 

The  TOTAL-!vEAD-WRITE-TIME  field  contains  the 
total  number  of  microseconds  during  which  the  current 
real  file  was  busy  with  read/writ-o  operations. 
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|*  Device  Set  Table  Duwp 

r 

<  The  Device  Set  Table  Dunqp  provides  a  printout 

for  each  physical  device  utilized  by  the  current  sim> 
ulation.  For  a  detailed  description  of  the  entries 
contained  in  the  device  set  table,  reference  the  des¬ 
cription  of  T15. 

DEV 

The  DEV  field  contains  the  number  of  the 
device  being  described  by  the  current  entry. 

ID 

The  ID  field  contains  the  transaction  item 
number  or  TO  transaction  item  number  which  has  seized 
this  device. 

AVAIL 

The  AVAIL  field  contains  the  number  of  the 
first  entry  in  the  availability  table  which  is  used 
to  describe  a  channel  control  unit  pcir  required  to 
reference  this  device. 

CLASS 

The  CLASS  field  describes  the  nunb-ir  of  the 
entry  in  the  device  class  table  which  will  be  used  to 
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provide  the  physical  device  description  for  this 
device. 

T-F 

The  T-F  field  contains  the  number  of  the 
first  entry  in  the  to-from  table  used  for  this  device. 
WIDTH 

The  WIDTH  field  contains  the  width  of  the 
to-from  table  which  has  been  constructed  for  this 
device . 

RCu-LOC 

The  REL-LOC  field  contains  the  relative 
location  of  the  ''.:.st  file  referenced  on  the  current 
device . 

SEIZE^CD 

The  SEIZE-Cn  field  contains  the  seizing  code 
for  the  current  device.  If  the  seising  code  is  one, 
the  device  may  be  seized  by  a  transaction.  If  the 
seizing  code  is  2  the  device  may  not  be  seized  by  any 
transaction. 

LAST  TIME 

The  LAST  TI>6i  field  contains  th«'  tics' 

at  trtiich  this  device  finished  itv  lO  o;)erati*»n. 
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TOTAL  SEEK  TIME 


The  TOTAL  SEEK  TIME  field  contains  the  total 
number  of  microseconds  which  have  been  used  for  seek 
operations  on  this  device. 

TOTAL  USE  TIME 

The  TOTAL  USE  TIME  field  contains  the  total 
number  of  microseconds  uuring  which  this  device  was 
busy  with  non-seek  operations. 

TOTAL  PEN  TIME 

The  TOTAL  PEN  TIME  field  contains  the  total 
number  of  microseconds  of  penalty  time  charged  to  this 
device . 
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Availabi-lity  Table  Dump 


The  Availability  Table  Dump  provides  a 
printout  of  each  entry  contained  in  the  availability 
table.  For  a  detailed  description  of  each  entry  in  the 
availability  table  reference  the  description  of  T36. 

ENTRY 

The  ENTRY  field  contains  the  number  of  the 
entry  in  the  availability  table  which  is  being  des¬ 
cribed. 

PATH 

The  PATH  field  contains  a  code  which  des¬ 
cribes  the  direction,  of  the  path  provided  by  the 
channel  control  unit  pair  described  on  the  right.  In 
addition,  if  the  path  code  is  negative  it  indicates 
that  this  is  the  last  entry  in  a  series  of  availability 
table  entries  for  a  single  device. 

CHANNEL 

The  CHANNEL  field  contains  the  number  of  the 
channel  which  may  be  used  with  the  control  unit  numbered 
on  the  right  to  provide  a  path  to  the  device  which  points 
to  this  entry  in  the  availability  table  dump. 
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CONTROL 


The  CONTROL  field  contains  the  number  of  the 
control  unit  which  may  be  used  with  the  channel  number 
provided  on  the  left  to  provide  a  path  to  the  device 
which  points  to  this  entry  in  the  availability  table. 


Channel  Table  Dnmi 


The  Channel  Table  Dump  provides  a  printout 
of  each  entry  contained  in  the  channel  table  for  the 
current  simulation.  For  a  detailed  description  of  the 
entries  in  the  channel  table,  reference  the  description 
of  T17. 

CHANNEL 

The  CHANNEL  field  contains  the  number  of  the 
channel  which  is  being  described  by  this  entry  in  the 
channel  table  dump.  Notice  that  two  entries  in  sequence 
may  have  the  same  channel  number.  In  this  event,  the 
channel  being  described  is  a  multiplexor  channel. 

MAX -RATE 

The  MAX-RATE  field  contains  the  maximum 
transfer  rate  in  characters  per  second  of  the  current 
channel . 

PERCENT-INTER 

The  PERCENT-INTER  field  contains  the  percentage 
interference  per  thousand  character  per  second  transfer 
rate  which  will  be  generated  by  the  current  channel. 
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TOTAL  TIME  IN  USE 


The  TOTAL  TIME  IN  USE  field  provides  the  total 
number  of  microseconds  during  which  this  channel  was  in 
use. 

TOTAL  LOAD  IN  CHAR 

The  TOTAL  LOAD  IN  CHAR  field  contains  the 
total  number  of  characters  transmitted  by  the  current 
channel . 

ID-OR-MPX~RATE 

The  ID-OR-MPX-RATE  field  contains  the  number 
of  the  seizing  transaction  item  for  a  selector  channel 
or  the  current  transfer  rate  for  a  multiplexor  channel. 


Control  Unit  Table  Dump 


The  Control  Unit  Table  Dump  provides  a 
printout  of  each  entry  in  the  control  unit  table. 

For  a  detailed  description  of  the  entries  in  the 
control  unit  table  reference  the  description  of  T18. 
CONTROL 

The  CONTROL  field  contains  the  number  of  the 
control  unit  being  described  by  this  entry. 

The  ID  field  contains  the  number  pf  the  trans* 
action  item  which  has  seized  this  control  unit.  ' 
TOTAL-USE-TIME 

The  TOTAL-USE -TIME  field  contains,  the  total 
number  of  mi,:roseconds  during  which  the  current  control 
unit  was  busy. 
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Device  Class  Table  Dump 


The  Device  Class  Table  Dump  provides  a 
printout  of  each  entry  in  the  device  class  table. 

For  a  detailed  description  of  the  individual  entries 
in  the  device  class  table  reference  the  description 
of  T19. 

CLASS 

The  CLASS  field  contains  the  number  of  the 
entry  in  the  device  class  table. 

TYPE 

The  TYPE  field  contains  a  code  which  describe 
the  type  of  device  being  defined  by  this  device  class 
table  entry. 

TRANSFER-RATE 

The  TRANSFER-RATE  field  con-d.ns  the  transfer 
rate  expressed  in  characters  per  second  for  the  device 
being  described  by  this  entry. 

WIDTH 

The  WIDTH  field  describes  the  transfer  width 
to  this  device  in  bytes. 
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START+STOP 


The  START+STOP  field  contains  the  total 
START+STOP  time  required  for  this  device  expressed 
in  microseconds. 

DEVICE -TIME 

The  DEVICE-TIME  field  contains  the  total 
amount  of  device  time  expressed  in  microseconds  required 
for  this  device. 

PENALTY-LIMIT 

The  PENALTY-LIMIT  field  contains  the  total 
number  of  microseconds  permitted  between  10  operations 
on  this  device  before  a  penalty  time  will  be  invoked. 
PENALTY 

The  PENALTY  field  contains  the  total  amount  of 
time  expressed  in  microseconds  to  be  added  to  each  10 
operation  which  requires  a  penalty  on  this  device. 

REWIND -MIN 

The  REWIND-MIN  field  contains  the  total  time 
expressed  in  microseconds  to  rewind  a  tape  device. 
FORM-TIME 

The  FORM-TIME  field  contains  the  total  time 
to  skip  one  line  if  the  current  device  is  a  printer. 
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General  Simulation  Table  Dump 


The  General  Simulation  Table  Dump  provides 
a  printout  of  each  of  the  important  fields  contained 
in  the  general  simulation  table.  For  a  detailed 
description  the  organization  of  the  fields  in  the 
general  simulation  table,  reference  the  description  of 
T20. 

CURRENT  CPU 

The  CURRENT  CPU  field  contains  the  number  of 
the  CPU  which  is  currently  executing  statements  in  the 
simulator. 

PROGRAM  TYPE 

The  PROGRAM  TYPE  field  contains  the  number  of 
the  worker  routine  for  which  the  current  transaction  is 
operating. 

OPERATION  CODE 

The  OPERATION  CODE  field  contains  the  number 
of  the  current  statement  being  executed  by  the  sim^ 
ulator . 


OPERAND-N 


Ihe  OPERAND-N  field  contains  the  value  of 
the  operand  whose  number  is  N. 

SUB  ERROR  CODE 

The  SUB  ERROR  CODE  field  contains  the  m  •'iber 
of  the  error  found,  if  any,  by  the  subroutine  whose 
number  is  given  below. 

NSI  CODE 

The  NSI  CODE  field  contains  the  number  of 
instz v-Ctions  which  are  to  be  skipped  before  the  next 
sequential  instruction  is  accessed. 

CURRENT  TIME 

The  CURRENT  TIME  field  contains  the  current 
value  of  the  simulated  clock  contained  in  the  simulator. 
The  time  given  by  this  field  is  expressed  in  sii'-ro- 
seconds . 

SUBROUTINE  NUMBER 

The  SURIOUTINE  SVmEH  field  contains  the  number 
of  the  subroutine  which  i>  currently  being  executed  by 
the  simulator. 
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FEC  CODE 


The  FEC  COTE  field  contains  the  last  FEC  COTE 
used  by  the  PUT  FEC  subroutine. 

FEC  ITEM 

The  FEC  ITEM  field  contains  the  number  of  the 
last  item  used  by  the  PUT  FEC  subroutine. 

STORAGE  CONT 

The  STORAGE  CONT  field  contains  the  value 
of  the  storage  contiguity  code  entered  for  the  current 
simulation. 

MEM  OP  1 

* 

The  MEM  OP  1  field  contains  the  number  of 
the  first  memory  referenced  by  the  last  MEMORY  statement 
MEM  OP  2 

The  MEM  OP  2  field  contains  the  number  of  the 
second  memory  referenced  by  the  last  MEMORY  statement 
executed. 

LCA 

Tiie  LCA  field  contains  the  address  of  the 
largest  contiguous  number  of  pages  available  as  deter¬ 
mined  by  the  last  MEMORY  statement  executed. 


LCR 


The  LCR  field  contains  a  count  of  the  largest 
number  of  pages  of  contiguous  storage  required  to 
satisfy  the  last  MEMORY  statement. 

SCA 

The  SCA  field  contains  the  address  of  the 
second  largest  cont.lgui.  is  storage  area  required  to 
satisfy  the  last  MEMORY  statement. 

SCR 

The  SCR  field  contains  the  count  of  the  total 
number  of  pages  needed  to  satisfy  the  second  largest 
contiguous  storage  requirement  for  the  last  MEMORY 
statement  executed. 

NCR 

The  NCR  field  contains  a  count  of  the  total 
number  of  noncontiguous  pages  required  to  satisfy  the 
last  MEMORY  statement  executed. 

MEMORY  TI 

The  MEMORY  TI  field  contains  the  number  of 
the  transaction  item  for  which  the  MEMORY  statement 
was  executed  last. 
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PACK  CODE 


The  PACK  CCX}E  field  contains  a  code  which 
determines  whether  a  pack  is  required  to  satisfy  the 
last  MEMORY  statement  executed. 

INTERRUPT  CODE 

The  INTERRUPT  CCX}E  field  contains  the  current 
interrupt  number  as  determined  by  the  FEC  manipulator. 
FEC  MANIP  TIME 

The  FEC  MANIP  TIME  field  contains  the  time 
at  which  the  last  item  placed  on  the  future  events 
chain  will  be  removed  from  that  chain. 

* 

FEC  POINTER  .  . 

The  FEC  POINTER  field  contains  the  number  of 
the  last  entry  on  the  future  events  chian  which  was 
altered  by  the  FEC  manipulator. 

MEMORY  UNIT  •  ’ 

The  MEMORY  UNIT  field  is  utilized  by  SMI  and 
cleared  before  SM2  begins  execution. • 

GEN  TI  PROG  NUMBER 

The  GEN  TI  PROG  NUMBER  field  contains  the 
number  of  the  transaction  last  generated  by  the 
generate  transaction  subroutine. 


D-49 


GEN  lOTI  TI  NUMBER 


The  GEN  lOTI  TI  NUMBER  field  contains  the 
nimber  of  the  last  10  transaction  item  generated. 

STANDARD  PRI 

The  STANDARD  PRI  field  contains  the  standard 
priority  which  is  to  be  assigned  to  any  worker  routine 
which  does  not  have  its  own  priority. 

STAT  INTERVAL 

The  STAT  INTERVAL  field  contains  the  time, 
expressed  in  microseconds,  between  statistical  intervals, 
NEXT  STAT  TIME 

The  NEXT  STAT  TIME  field  contains  the  time, 
expressed  in  microseconds,  at  which  statistics  will 
next  be  printed  out . 

TOTAL  NUMBER  STATS 

The  TOTAL  NUMBER  STATS  field  contains  a  count 
of  the  total  number  of  statistical  intervals  to  be 
printed.  , 

NUMBER  STATS  DONE 

The  NUMBER  STATS  DONE  field  contains  a  count 
of  the  total  number  of  statistical  intervals  which 
have  been  completed. 
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TI  ADDR 


The  TI  ADDR  is  not  used  in  the  current 

simulator . 

INTERFERENCE 

The  INTERFERENCE  field  contains  the  current 
interference  rate  existing  in  the  simulator. 

INT  START  TIME 

The  INT  START  TIME  field  contains  the  time, 
expressed  in  microseconds,  at  which  the  current  inter¬ 
ference  rate  began. 

INT  SEC 

The  INT  SEC  field  contains  the  total  number 
of  interference  microseconds  which  have  been  accumulated 
in  the  simulator. 

QUEUE  LIMIT 

The  QUEUE  LIMIT  field  contains  the  address  of 
the  last  entry  in  a  queue  entry  table  for  the  queue 
which  is  currently  being  manipulated. 

QUEUE  INCREMENT 

The  QUEUE  INCREMENT  field  contains  the  number 
which  will  be  added  to  the  queue  pointer  to  get  the  next 
entry  in  the  current  queue. 

D-61 


If 


RANDOM  NUMBER 


The  RANDOM  NUMBER  field  contains  the  last 
random  number  generated  by  the  simulator. 

RANDOM  NUMBER  SEED 

The  RANDOM  NUMBER  SEED  field  contains  the 
nvimber  to  which  the  random  number  ge*'  rator  was 
initialized. 

INT  RANDOM  NUMBER 

The  INT  RANDOM  NUMBER  field  contains  the 
binary  random  number  expressed  as  an  integer  value. 
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Function  Table  Dump 


The  Function  Table  Dump  provides  a  printout 
of  each  entry  contained  in  the  function  table.  For  a 
detailed  description  of  the  function  table  entries 
reference  the  description  of  T21. 

FUNCTION 

The  FUNCTION  field  contains  the  number  of 
the  current  entry  in  the  function  tabl^ . 

CHANNEL-TIME 

The  CHANNEL-TIME  field  contains  the  time, 
expressed  in  microseconds,  for  which  the  channel 'i!:  to 
be  busy  when  this  function  number  is  used  by  a  function- 
statement. 

CONTROL-TI^^ 

The  CCWTROL-TIME  field  contains  the  time, 
expressed  in  microseconds,  for  which  the  control  unit 
is  to  be  busy  when  this  function  numljer  is  referenced 
by  a  function  statement. 


DEVICE-TIME 


The  DEVICE-TIME  field  contains  the  time, 
expressed  in  microseconds,  for  which  the  device  is 
to  be  busy  when  this  function  entry  is  referenced  by 
a  function  statement. 

DEV 

The  DEV  field  contains  the  number  of  the 
device  to  which  this  function  is  to  be  directed. 


statement  Table  Dump 


The  Statement  Table  Dump  provides  a  printout 
of  each  entry  In  the  statement  table.  For  a  detailed 
description  of  the  statement  table  entries  reference 
the  description  of  T22» 

Since  each  operation  code  and  operand  entered 
into  the  statement  table  takes  one  location  all  of  the 
values  contained  in  the  statement  table  are  printed  out 
in  a  large  rectangular  array.  The  statement  table  dump 
is  read  by  looking  down  the  nuod^er  colxmn  until  the 
address  desired  rounded  down  to  the  nearest  unit' of  ten 
is  found.  The  proper  entry  is  then  found  by  looking 
across  that  row  until  the  proper  unit  value-  is  found 
at  the  heading  of  the  column. 


Switch  Table  Dump 


The  Switch  Table  Dump  provides  a  printout 
of  all  of  the  current  values  in  the  switch  table.  For 
a  detailed  description  of  the  entries  found  in  the 
switch  table,  reference  the  description  of  T23. 

The  local  switches  numbered  1  to  20  for  CPU 

nujiber  1  will  be  found  in  the  switch  table  as  entries 

1  to  20.  The  local  switches  numbered  1  to  20  for  CPU 

number  2  will  be  found  in  the  switch  table  as  numbered 

from  21  to  40.  The  local  switches  numbered  1  to  20  for 
CPU  number  3  will  be  found  in  the  switch  table  as 
numbered  from  41  to  60.  The  local  switches  numbered 
from  1  to  20  for  CPU  number  4  will  be  found  in  the 
switch  table  as  numbered  from  61  to  80.  The  local 
switches  numbered  from  1  to  20  for  CPU  number  5  will 
be  found  in  the  switch  table  as  numbered  from  81  to  100. 
The  global  switches  available  to  all  CPU's  numbered 
from  101  to  200  will  be  found  under  the  same  numbers 
in  the  switch  table  dump. 

The  switch  table  dump  is  referenced  in  the 
same  way  as  the  statement  table  dump. 
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The  TO-PROM  Table  Duoip  provides  a  printout 
of  the  current  values  for  each  entry  in  the  TO>FROM 
ti^le.  For  a  detailed  description  of  the  entries 
found  in  the  TO>FROM  tabla  reference  the  description 
of  T24. 

The  TO«FROM  table  is  referenced  in  the  sane 
■anner  as  the  statements  table  and  switch  table. 
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Mark  Time  Table  Dumi 


The  Mark  Time  Table  Dump  provides  a  detailed 
printout  of  the  current  values  of  all  of  the  mark  timo 
accumulators  in  the  current  simulation.  The  mark  number 
accumulators  are  numbered  ordinally  as  indicated  on  the 
printout  and  the  time  accumulated  in  each  of  the  mark 
time  accumulators  is  expressed  to  the  right  in  micro¬ 


seconds. 


SNAP  Dump 


rhie  SNAP  Dump  provides  a  more  detailed 
printout  of  the  current  simulator  status  than  the 
TRACE  Dump.  A  SNAP  Dump  is  printed  each  time  there 
is  a  change  in  the  current  operating  CPU,  current 
operating  transaction,  available  transaction,  or 
I/O  transaction  item.  The  information  used  by  the 
SNAP  Dump  is  obtained  from  the  tables  maintained 
by  the  simulator. 

SNAP  NUMBER 

The  SNAP  NUMBER  field  contains  the  number  of 
the  current  SNAP  Dump. 

CPU 

The  CPU  field  cont^dns  the  number  of  the 
current  operating  CPU. 

COT 

The  COT  field  contains  the  number  of  the 

» 

current  operating  transaction. 

The  AT  field  contains  the  number  of  the 


current  available  transaction. 


lOT 

The  lOT  field  contains  the  number  cf  the 
current  I/O  transaction  itom. 

TIME 

The  TIME  field  contains  the  current  simulated 

time . 

FEC-CD 

The  FEC-CD  fxald  contains  the  current  FEC 
CODE  from  the  general  simulation  table. 

ITEM 

The  ITEM  field  contains  the  current  FEC  ITEM 
from  the  general  simulation  table. 

SUB 

The. SUB  field  contains  the  current  subroutine 
number  from  the  general  simulation  table. 

INT 

The  INT  field  contains  the  current  interrupt 
number  from  the  genrral  simulation  table. 

NSI 

The  NSI  field  contains  the  current  next 
sequential  instruction  counter  from  the  general 
simulation  table. 
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The  line  which  begins  with  the  COX  field 
describes  the  current  operating  transaction. 

W/R 

The  W/R  field  contains  the  number  of  the 
worker  routine  for  which  the  current  operating  trans- 
actio;:^  is  being  executed. 

OFN 

The  OFN  field  contains  the  current  ordinal 
file  request  for  the  current  operating  transaction. 

ID 

The  ID  field  contains  the  identification 
number  for  the  current  operati.ig  transaction. 

R-C 

The  R-C  field  contains  a  pointer  to  the 
run  class  for  the  current  operating  transaction. 

PRI 

The  PRI  field  contains  the  priority  of  the 
current  operating  transaction. 


NSI 


The  NSI  field  contains  the  next  sequential 
instruction  pointer  for  the  COT. 
lOT 

The  lOT  field  contains  a  count  of  the  number 
of  I/O  transaction  items  outstanding  for  the  COT. 

TYPE 

The  TYPE  field  contains  the  program  type 
for  the  COT. 

LA-n  LX:-n 

The  LA-n  LC-n  fields  contain  the  loop  address 
and  loop  counter  respectively  for  the  loop  whose'  level 
is  n.  > 

S-n 

the  S-n  field  contains  the  next  sequential 
instruction  counter  for  the  'subroutine  whose  level  is 
n. 

The  P-L  field  contains  the  •.u^.iher  of  S|>aces 
required  for  the  last  PRINT  statement  exectued. 

T-P 

The  T-P  field  contains  the  address  of  the 

tiiN}  section  of  the  current  operating  transaction. 
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F-P 


The  F~P  field  contains  the  address  of  the 
file  section  for  the  COT. 

FBC 

The  PEC  field  contains  the  number  of  the 
CPU  which  last  put  the  COT  on  the  future  events  chain. 
CREATION 

The  CREATION  field  contains  the  time  at  which 
the  current  transaction  was  created. 

TIME-OFF-FEC 

The  TIMB-OFF-FEC  field  contains  the  time  at 
which  the  current  transaction  last  cane  off  the  future 
events  chain. 

APV-TI>C 

The  ADV-TIME  field  contains  the  tine  which 
the  current  transaction  must  spend  on  the  future  events 
chain  before  it  nay  exectue  the  next  statement. 

CPU»TII>C 

The  CPU'TINB  field  contains  the  total  amount 
of  CPU  tine  utilised  by  the  current  transaction. 
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Q-.SRT-TIME 


Tne  Q-SRT-TIME  field  contains  the  time  at 
which  the  current  transaction  item  was  placed  on  a 
queue  if  it  is  currently  on  a  queue. 

T1->QUBUE-T 

The  TI-QUEUE-T  field  contains  the  total 
amount  of  time  which  the  current  operating  transaction 
has  spent  on  all  queues. 
lOT-QUEUE-T 

The  lOT-QUEUEoT  field  contains  the  total 
amoimt  of  time  which  I/O  transaction  items  associated 
with  the  current  operating  transaction  has  spent  on 
queues . 

B«n 

The  B«n  field  contains  the  number  of  buffers 
available  for  the  ordinal  file  numbered  n. 

R-n 

The  R-n  field  contains  the  total  number  of 
records  available  for  the  ordinal  file  numbered  n. 

T»n 

The  T-n  field  contains  the  total  number  of 
10  operations  performed  for  the  ordinal  file  numbered 
n. 
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TRACE  Dumr 


The  TRACE  Dxiap  provides  a  single  line  of 
inforaation  about  the  current  status  within  the 
siaulator  each  tine  a  new  subroutine  is  executed. 

This  information  is  extracted  from  a  number  of 
tables  maintained  by  the  simulator. 

NUMBER 

The  NUMBER  field  provides  a  line  count  for 
the  TRACE  subroutine. 

CPU 

The  CPU  field  contains  the  number  of  the 
current  operating  CPU. 

COT 

The  COT  field  contains  the  number  of  the 
current  operating  transaction  for  the  current  operating 
CPU. 

The  AT  field  contains  the  number  of  the 
available  transaction  it  any  for  the  current  CPU. 
lOT 

The  TOT  field  contains  the  number  of  the 
TO  transaction  for  the  current  CPU. 
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OP 

The  OP  field  contains  the  current  operation 
code  for  the  current  operating  CPU. 

F»n 

The  P-n  field  contains  the  operand  whose 
number  is  n  for  the  current  operating  CPU. 

TIME 

The  TIME  field  contains  the  current  simulated 

time . 

P-CD 

The  P~CD  field  contains  the  PBC  CODE  from 
the  general  simulation  table. 

ITEM 

The  ITEM  field  contains  the  PEC  ITEM  field 
from  the  general  simulation  table. 

SUB 

The  SUB  field  contains  the  number  of  the  sub¬ 
routine  which  is  currently  being  executed. 

INT 

The  INT  field  contains  the  current  interrupt 
nuaiber  from  the  general  simulation  table. 
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COT-NSI 


The  COT-NSI  field  contains  the  next  sequential 
instruction  pointer  for  the  current  operating  trans¬ 
action. 

AT-NSI 

Tl'e  AT-NSI  field  contains  the  next  sequential 
instruction  pointer  for  the  available  transaction  if 
any . 

NSI 

The  NSI  field  contains  the  next  sequential 
instruction  counter  from  the  general  sinulation  table. 
This  field  indicates  how  many  instructions  are  to  be 
skipped  before  the  next  operation  code  is  accessed. 

ERR 

The  ERR  field  contains  the  error  code  froa 
the  general  sieulation  table. 

PROG 

The  PROG  field  contains  the  nuaber  of  the 
worker  routine  which  is  currently  being  executed. 

RAND 

pie  RAND  field  contains  the  current  randoa 
nuaber  frcm  the  general  siaulation  table. 
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lOT 


The  lOT  field  informs  the  user  that  the 
line  of  information  which  follows  describes  the  current 

10  transaction  item  if  any. 

11 

Tlie  TI  field  contains  the  number  of  the 
transaction  item  which  generated  this  I/O  transaction 
item. 

FEC 

The  FEC  field  provides  a  count  of  the  number 
of  times  a  pointer  to  this  I/O  transaction  item  appears 
on  the  future  events  chain. 

TYPE 

The  TYPE  field  contains  a  code  which  describes 
the  type  of  I/O  transaction  item. 

CPU 

The  CPU  field  contcins  the  number  of  the  CPU 
which  created  this  I/O  transaction  item. 

CHAN 

The  CHAN  field  contains  the  number  of  the 
channel  which  is  being  used  by  this  I/O  transaction 
item. 
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CPL 


The  CPL  field  contains  the  niuiber  of  the 
control  unit  being  used  by  this  I/O  transaction  item. 
DSV 

The  I£V  field  contains  the  number  of  the 
device  being  used  by  this  I/O  transaction  item. 

RFN 

The  RPN  field  contains  the  niusber  of  the 
real  file  for  v^ich  this  I/O  operation  is  being  per¬ 
formed. 

OFN 

The  OPN  field  contains  the  ordinal  file 
number  for  which  this  I/O  transaction  item  is  being 
performed. 

The  F-NUMaSR  field  contains  the  function 
number  which  was  used  to  generate  this  I/O  trans¬ 
action  item,  if  any. 

CHAWNBL»END 

The  CHANNBL-BND  field  contains  the  time  at 
which  the  channel  being  used  by  this  I/O  operation 
will  be  released. 


CONTROL-ENO 


The  CONTROL-END  field  contains  the  tine  at 
which  the  control  unit  being  used  for  this  I/O  operation 
will  be  released. 

DEVICE-END 

The  DEVICE-END  field  contains  the  time  at 
which  the  device  being  used  by  this  I/O  operation  will 
be  released. 

Q-START 

The  Q-START  field  contains  the  time  at  which 
this  I/O  transaction  item  was  placed  on  a  queue  if  it 
is  currently  on  a  queue. 

The  Q-IOT  field  contains  the  total  awount  of 
tiM  this  I/O  transaction  item  has  spent  on  queues. 
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FILE 


The  FILE  field  informs  the  user  that  the 
following  line  of  information  describes  the  file 
being  used  by  the  I/O  transaction  item,  if  any. 

ID 

The  ID  field  contains  the  number  of  the 
transaction  which  has  seized  this  file. 

DEV 

The  DEV  field  contains  the  number  of  the 
device  on  which  this  file  resides. 

The  LOC  field  contains  the  relative  location  . 
of  this  file  on  the  device  described. 

BUFF 

The  BUFF  field  contains  the  length  of  the 
buffer  required  to  READ  from  or  WRITE  to  this  tile. 

REC 

The  REC  field  contains  a  count  of  the  number 
of  records  conlained  in  a  single  buffer  on  this  file. 
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SIZE 


The  SIZE  field  contains  the  total  number  of 
blocks  contained  in  this  file, 

TIME-SEIZED 

The  TIME-SEIZED  field  contains  the  time  at 
which  this  file  was  last  seized. 

T-TIME-SEIZED 

The  T-TIME-SEIZED  field  contains  the  total 
amount  of  time  during  which  this  file  has  been  seized. 
R/W  TIME 

The  R/W  TIME  field  contains  the  total  amount 
of  time  during  which  this  file  was  busy  with  READ  or 
WRITE  operations. 
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DEV 


The  DEV  field  informs  the  user  that  the 
line  which  follows  describes  the  device  being  used 
by  the  current  I/O  transaction  item,  if  any. 

ID 

The  ID  field  contains  the  number  of  the 
transaction  which  has  seired  this  device. 

AVAIL 

The  AVAIL  field  contains  the  address  of  the 
availability  table  entry  for  this  device. 

CLASS 

The  CLASS  field  contains  the  address  of  the 
device  class  describing  this  physical  device. 

T-F 

The  T-F  field  contains  the  address  of  the 
to-from  table,  if  any.  used  for  this  device. 

SIZE 

The  SIZE  field  contains  the  size  of  each 
entry  in  the  to-from  table  described  previously. 
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L-F 

The  L-F  field  contains  the  number  of  the 
last  file  referenced  on  this  device. 

OD 

The  CD  field  contains  a  code  vihich  deter¬ 
mines  whether  the  current  device  may  be  seized  or  not. 
LAST-END-TIME 

The  LAST-BND-XIME  field  contains  the  time  at 
which  this  device  was  last  freed. 

TOT-SEEK -TIME 

The  TOT-SEEK-TIME  field  contains  the  total 
amount  of  tiiK  seeking  on  the  current  device. 
TOT-USE-TIME 

The  TOT-USE-TIME  field  contains  the  total 
amount  of  time  used  on  this  device. 

PENALTY-TIME 

The  PENALTY-TIME  field  contains  the  total 
amount  of  time  performing  penalty  operations  used  on 
this  device. 
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CHAN 


The  CHAN  field  informs  the  user  that  the 
following  line  describes  the  channel  baing  utilized 
by  the  I/O  transaction  item,  if  any. 

ID 

The  ID  field  contains  the  transaction  nuiaber 
of  the  transaction  currently  using  this  channel. 

RATS 

The  RATE  field  contains  the  maximum  transfer 
rate  available  on  this  channel. 

INTER 

The  INTER  field  contains  the  percentage 
interference  per  thousand  characters  per  second  transfer 
rate  for  the  current  channel. 

USE-TIME 

The  USE-TIME  field  contains  the  total  amount 
of  time  the  current  channel  has  been  used. 

LOAD 

The  LOAD  field  contains  the  total  number  of 
characters  transferred  over  this  channel. 
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MPX-RATE 


The  MPX-RATB  field  contains  the  current 
transfer  rate  if  the  channel  is  being  used  in  Multi¬ 
plexor  node. 

MAX-RATB 

The  MAX-RATE  field  contains  the  naxiaua 
peraissable  transfer  rate  for  this  channel  when 
operating  in  multiplexor  mode. 

INTER 

The  INTER  field  contains  the  interference 
rate  for  the  current  channel  when  used  in  multiplexor 
mode* 

LOAD 

The  LOAD  field  contains  the  number  of 
characters  transmitted  across  this  channel  in  multi¬ 


plexor  mode 
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